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] |
Andrew Cagney wrote:
Symbol table code often returns 0 to indicate a failed lookup (here a search for the function containing pc). That zero can end up in the frame ID. Look at calls to get_frame_func / frame_func_unwind (which I've proposed eliminating).
From memory architectures that do not implement dummy ID unwind also end up with wild-card IDs (fortunatly the dummy-frame code works around this).
Broken tramp unwinders often leave the .code address zero (see paragraph #1 for why).
So, what would you recommend to solve the problem of 'wildcard zero pc' being confused with 'NULL pointer call'? Is my original back-end hack OK with or, or do you have another target-independent suggestion?
/* Construct a frame ID. The first parameter is the frame's constant stack address (typically the outer-bound), and the second the frame's constant code address (typically the entry point) (or zero, to indicate a wild card). The special identifier address is defaulted to zero. */ extern struct frame_id frame_id_build (CORE_ADDR stack_addr, CORE_ADDR code_addr);
/* Construct a special frame ID. The first parameter is the frame's constant
stack address (typically the outer-bound), the second is the
frame's constant code address (typically the entry point) (or zero,
to indicate a wild card), and the third parameter is the frame's
special identifier address (or zero to indicate a wild card or unused default). */
extern struct frame_id frame_id_build_special (CORE_ADDR stack_addr,
CORE_ADDR code_addr,
CORE_ADDR special_addr);
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |