This is the mail archive of the gdb-patches@sourceware.org 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] |
On Tuesday, December 14, 2010 04:37:35 Andrew Stubbs wrote: > On 13/12/10 18:43, Pedro Alves wrote: > > Hmmm. These last 6 look to be some kind of pseudo registers, not > > part of the ISA -- I'm quite surprised to see these here, as > > part of the bfin core register set. I understand these to be > > fdpic related; ISTR some discussion about making these be reported > > with a new qXfer object? That'd be better, IMO. > > Right, the SH-2A FDPIC implementation uses qXfer to deal with the FDPIC > settings. The SG++ gdb has a (more-or-less) target independent mechanism > for retrieving the load maps. This has not been submitted upstream > simply because it's not complete. The SH-2A FDPIC kernel does (did) not > support breakpoints, and single stepping is (was) rather broken, so I > never got further than being able to relocate the main program. > > For SH-2A, at least, the kernel does not expose the load maps as > registers, but has extra ptrace queries PTRACE_GETFDPIC_EXEC and > PTRACE_GETFDPIC_INTERP. > > The gdbserver reads these via qXfer:fdpic:read:exec and > qXfer:fdpic:read:interp. but the SuperH/FDPIC port is still out of tree right ? so i cant review it to see if i can leverage it ... if the gdbserver code can remain backwards compatible with the Linux ABI, then i dont have a problem changing to a qXfer style. -mike
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] |