This is the mail archive of the gdb@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] |
Hello,
To put it simply, how can one fix this:
static CORE_ADDR d10v_read_pc (ptid_t ptid) { .... read_register (PC_REGNUM); .... }
There are problems at many levels. Off the top of my head:
- ptid can identify a thread and/or a LWP - there sometimes isn't even a thread and/or a LWP - the selected and current thread both fight over the same global data structures - long long term, an objective is to have gdb debug multiple processes / ISAs - so long term that it is probably funny, an objective is to have gdb debugging multiple targets
I think we've fought the frame battle and won (the casualties will take ages to recover mind :-), the thread battle, I think, is next.
On Mar 2, 3:25pm, Andrew Cagney wrote:
Following on from my recent post to add an unwind_dummy_id() method, this code adds architecture specific methods to handle the edge case of unwinding the sentinel frame's PC/ID.
While I'm pretty sure that the methods are needed, I'm not 100% certain of their interfaces. The attached has:
unwind_sentinel_id(arch, regcache, unwind_cache)
I'm wondering if, instead it should use something like:
unwind_sentinel_id(arch, tpid, unwind_cache)
where a new method:
tpid_regcache (tpid)
could be used to obtain the tpid's register cache. I'm thinking this since, for the case of the i386, it may need the thread's state in addition to registers when determing the `pc'.
s/tpid/ptid/ in the above.
ptid_regcache() does sound useful.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |