Re: Make CoredumpAction use Task.getRegisterBanks()

[Mark Wielaard <mark at klomp dot org>]

Hi Phil,

On Mon, 2007-07-30 at 12:44 -0500, Phil Muldoon wrote:
> Mark Wielaard wrote:
> > Phil and me were discussing cleaning up some of the
> > Memory/RegisterBuffers between ptrace and core proc Tasks on irc and
> > noticed that CoredumpAction was accessing the RegisterBanks directly
> > through the Isa. To make splitting the issue of getting the
> > RegisterBanks (Task specific) and doing the Register name mapping to
> > bank number and offset (Isa specific) easier we wanted to make all code
> > go through Task.getRegisterBanks(). This patch does that for
> > CoredumpAction:
> >   
> Looks good. The only function here is to attain the raw memory behind 
> the byte buffers for floating point registers, as that is dumped whole 
> into the FP Register Note.
> 
> CoredumpAction has been gutted locally and being refactored into a 
> Corefile{arch}factory. I'll take your patch and reconstitute it there

Thanks. Please let me know if I should hold off on the rest of the
register banks cleanup till you finished this. Or if you want me to take
a look at what you have now to get a better understanding how to clean
up these buffers.

For ptrace/proc based Tasks there are basically 4 register banks (not
all of them used on all architectures) the Isa provides a mapping from
the actual register names to the bank and offset inside it. The four
banks are the regular registers (gotten through PTRACE_GETREGS), the
general floating point registers (gotten through PTRACE_GETFPREGS), the
extended floating point registers such like sse xmm registers (gotten
through PTRACE_getXFPREGS) and the other registers (gotten through the
start of USR memory space) that cover things like debug control
registers found by the Isa through the mapping in sys/user.h (some of
the other register banks are actually also contained in this one).

Does this map somewhat to how core files handle the register banks, so
you can just dump/read these banks from them?

Cheers,

Mark