This is the mail archive of the frysk@sourceware.org mailing list for the frysk 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: Make CoredumpAction use Task.getRegisterBanks()


On Tue, 2007-07-31 at 19:26 -0500, Phil Muldoon wrote:
> Mark Wielaard wrote:
> >
> > 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?
> >   
> 
> Pretty much other than General Purpose registers which needs to be 
> accessed independently via getRegisterByName(). The the rest are just 
> dumped  wholesale into the notes, and in that instance accessed via 
> task.getRegisterBanks().

Thanks. So this seems slightly different from how we do things with
ptrace/proc where we can have multiple different register banks (for
floating point, extended floating point and control/debug registers). We
might be able to always just use the USR address space to get at all of
those together in one go (I don't actually know why we don't do that, or
why ptrace provides different ways to access the same register sets).

> I think, going forward access to the raw memory  for each register bank, 
> and also a getRegisterByName() function (which is the functionality we 
> have now) is needed, and probably will be down the line.

If we can match up the raw memory for each register bank between
ptrace/proc and core files from Task that would be ideal. Then the Isa
can just do the getRegisterByName() mapping. I'll watch your rewrite of
the core file stuff and see if this makes things easier and clearer (I
guess it will).

Cheers,

Mark

Attachment: signature.asc
Description: This is a digitally signed message part


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