Re: RFA: ia64 tdep patch

[Marcel Moolenaar <marcel at xcllnt dot net>]

On Thu, Oct 23, 2003 at 09:30:16PM -0700, Kevin Buettner wrote:
> > 
> > I'm leaning towards changing gdb. I just need to underdstand better
> > what I'm getting into. I have little experience with gdb...
> 
> If you take a look at the Linux/ia64 implementation of ptrace(),
> you'll see that some of this complexity has been moved into the
> ptrace() implementation.  ptrace() will get/set the user portion of
> registers stored in the kernel's register backing store.

Yes. The PEEK{DATA|TEXT} and POKE{DATA|TEXT} functions interpret
addresses between [bspstore, bsp> differently. Besides hiding the
fact that there are registers on the kernel stack that belong to
the process it also has the drawback that it makes it impossible
to actually read from the backing store between [bspstore, bsp>.

Also, reading from and writing to user memory is common code in
FreeBSD. I hate to make ia64 a special case only to hide some
details that a ptrace(2) user can deal with without too much
problems.

> >From what you said earlier, it sounds as though you'd already
> implemented something like this for FreeBSD...

It still requires a special ptrace(2) call, making the distinction
between flushed and dirty stacked registers explicit to gdb. It also
doesn't address how to handle coredumps. Having the dirty registers
in some note section to avoid modifying the state of the process
represented by the core file is appealing to me. This too makes it
explicit that dirty registers are special WRT flushed registers.

Again: by hiding the details, we obfuscate the true state of a
process. I can't stop thinking how that can make some class of
failures undebuggable (e.g. bugs related to NaT collections, near
stack overflow conditions, context switching bugs or maybe even
setjmp/longjmp bugs).

Thoughts?

-- 
 Marcel Moolenaar	  USPA: A-39004		 marcel@xcllnt.net