> From: rhealey@kas.helios.mn.org (Rob Healey)
> Subject: Re: gdb on m68k
> To: Paul.Mackerras@cs.anu.edu.au (Paul Mackerras)
> Date: Wed, 14 Sep 1994 08:21:00 -0500 (CDT)
> Cc: port-m68k@NetBSD.ORG, core@NetBSD.ORG
> 
> > Has anybody tried using GDB on any of the m68k ports lately?
> > When I tried, I got a message like "Error reading register pc (#17):
> > Invalid operation".
> > 
> 	We've been knocking our heads against the wall for weeks on this
> 	one. It appears to have happened when some other port made some
> 	serious changes in ptrace... B^(.
> 
Somebody did this in the 4.4 sources at CSRG also.  One of the Sparc or
Mips guys went in and forced 4-byte alignment.  I changed it back to 2-byte
for the 68k (though not even that is necessary on the 020 and beyond) so
either I did that after 4.4-lite went out or else someone did the same thing
to the netbsd version.

> 	Is you solution a quicky hack or a good long term solution? I.e.
> 	is there some other way other than deactivating 32 bit alignment
> 	in m68k kernels? The amiga port had problems when the alignment checks
> 	we simply removed, i.e. lockups.
> 
A couple of long term solutions:

1. Ditch ptrace.  Don't know if /proc is ready for prime time though.

2. Modify ptrace to return more than one word at a time and add GETREG
   and SETREG calls.

One possible medium term solution:

3. Add {GET,SET}REG{0,1,..} type calls to return/set each register.

This doesn't work too well with FP regs (>32 bits) though and is pretty
lame all-in-all.  I would stick with the no-alignment hack before resorting
to this.  The point of #2 and #3 is that it makes the registers special to
the ptrace code so it knows no alignment checks are necessary and the
debugger is freed from the gruesome task of determining magic u-area offsets
to locate saved registers.

#2 has been done by others (e.g. HP-UX) and could have a positive
impact on performance.  Right now you have to do 32 or so context switches
every time you read the registers (e.g. when you hit a breakpoint).