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] |
The, in theory, operation:A frame that gets the saved registers from the register cache. As for uses:
- an inner-most frame that for some reason doesn't unwind (i.e., create_new_frame() barfs).
- the frame that is inner to `current frame'.
I'm confused again :) "Current frame" is one which does not unwind, right? No saved PC, no saved registers. The concepts are meaningless. Its frame ID corresponds (very) loosely to the current stack pointer. This would be frame #0 in a backtrace. There's nothing inside of it.
INIT_FRAME_EXTRA_INFO() can throw an error. For instance, due to an attempt to read from an address specified by PC/FP/SP when that address is invalid. For such cases, there should still be a current frame (so that `info registers' works) but it shouldn't unwind any further.Or are you saying that the innermost frame is this special regs-frame, and the current frame (still #0) is outside of that? OK, that jives with some things I remember you describing earlier. Makes sense now. I don't see what you mean by "doesn't unwind", since we always start with having the current frame (i.e. there would be at least two) but I think I'm back on your page again.
Need to figure out how/were this should tie into the rest of the frame structure. The CFI code is not exactly integrated into the mainstream.>As for this situation, and the similar one for i386... there are three >unwind functions, to find the previous frame's registers, ID, and PC. >For this case we just want to express a normal function call which >saves no registers; pretty easy. But for i386 I'll want to express >something which initially pushes a register, and then does some work, >pops it, and does more work before returning.
So you're proposing that the saved-regs code be used to generate a cfi description as well?
Interesting.
Precisely. When given a function without enough information to backtrace through it in the debug info, the prologue scanner could implement this new method in order to provide backtraces. It could really clear up some messes. I think it's a promising idea.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |