Re: RFA: ia64 tdep patch

[Kevin Buettner <kevinb at redhat dot com>]

On Oct 23,  4:22pm, Marcel Moolenaar wrote:

> On Thu, Oct 23, 2003 at 02:00:49PM -0700, Kevin Buettner wrote:
> > On Oct 22,  3:02pm, Marcel Moolenaar wrote:
> > 
> > > > They are needed because r32 to r127 are not accessible via the PTRACE 
> > > > interface. They are accessed via the bsp.  Without flagging them as 
> > > >  pseudo-registers, the regcache code returns 0 for all these registers.
> > > 
> > > It depends. For FreeBSD I added ptrace(2) functions to get and set
> > > stacked registers that are on the kernel stack. The problem more
> > > generally is that registers above bspstore (but below bsp) are
> > > not accessable in memory. I think it's better for gdb to keep the
> > > distinction between stacked registers on the backing store and
> > > "dirty" stacked registers. The distinction avoids that gdb makes
> > > assumptions that are only valid on Linux or even only for the native
> > > code.
> > 
> > Unfortunately, the assumptions that you mention are already in place.
> > (And have been in place for quite some time).
> 
> Yes, and it is one of the pickles I'm working on. Do I change FreeBSD
> to match the assumption in gdb or do I change gdb to remove the
> assumption?
> 
> One technical reason for removing the assumption in gdb is that it
> is not always possible to flush the dirty registers onto the user
> backing store. It could fail when BSPSTORE is close to or at the
> boundary of the register stack. This is a border case, but it would
> be impossible to debug a process when it actually operates under
> these conditions. Also, when flushing the dirty registers onto the
> user backing store, we change the state of the process, which may
> hide the problem and interfere with debugging. It's mostly academic,
> but still a fundamental "flaw" in debugging on ia64.
> 
> A technical reason for changing FreeBSD is that it avoids changing
> gdb and keeps access to the stacked registers uniform. However, even
> though debugging is not performance critical, moving the complexity
> into the debugger may avoid unnecessary and unconditional copying
> from the kernel stack to the user stack and gives gdb (or any other
> program that needs this) control over it...
> 
> 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.

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

> > > BTW: I have partial support for FreeBSD/ia64. I'll send patches as
> > > soon as I feel that the backtrace is reliable enough.
> > 
> > Patches will most certainly be welcome.  Do you have an FSF copyright
> > assignment for GDB yet?  If not, you might want to start working on
> > the paperwork now...
> 
> I do not have such assignment, but it's in the pipeline.

Cool.

Kevin