Re: RFA: ia64 tdep patch

[Marcel Moolenaar <marcel at xcllnt dot net>]

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...

> > 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.

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