This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA] W.I.P. AltiVec ppc registers support.


Kevin Buettner writes:
 > On Nov 29,  6:03pm, Andrew Cagney wrote:
 > 
 > > >> Unfortunately not. I thought the same, until I remembered about core
 > > >  > > file debugging. That function is called by fetch_core_registers() in
 > > >  > > core-aout.c.
 > > >  > > Hmm... I wonder if Linux/PPC even needs this function in core-aout.c.
 > > >  > Daniel J. is the expert on this stuff.  Daniel, doesn't Linux/PPC use
 > > >  > core-regset.c instead?
 > > >  > Whoops, yes, you are right. False alarm.
 > > 
 > > So just the core code needs to have a hard-wired (non native header) way 
 > > of unpacking Altivec registers (if they are found?)?
 > 
 > I'm guessing we'll end up having to add fetch_core_registers() and
 > company to ppc-linux-nat.c.  That way neither core-regset.c nor
 > core-aout.c will be used for a native Linux/PPC build.  (See
 > fetch_core_registers() in i386-linux-nat.c as an example.)

cross core file support: is that a concern?

Side bar: there is something interesting about the way the corelow.c
file gets the registers sections from a core file. It looks for .reg
(gregs), .reg2 (fpregs), and .reg-xfp (extended-floating point x86
only(?)). Seems like I'll have to add a fetch section call for a
.reg-altivec (or whatever it will be called, it's not produced
yet). But that's in common code.  I don't like it. This
get_core_registers() will have to be overwritten too, maybe.

Elena



 > 
 > Kevin


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]