[RFC] Unexpected automatic language switch - get_frame_language()
Sat Dec 6 00:42:00 GMT 2003
Joel Brobecker wrote:
>>Sounds kinda like a debugging-optimized-code problem. Your function
>>is tail-return optimized -- doesn't really return. That's outside
>>the expected API.
> Kind of, yes, but the code in question was compiled at -O0!
Never the less...
> It's a
> noreturn function because the compiler could statically determine that
> the exception would be unhandled.
Maybe the compiler shouldn't do that at -O0?
>>I think you have to do "special" things for non-returning functions.
>>I've seen the same sort of thing for eg. _exit.
> Do you remember how these similar problems were approached and solved?
Ummm... ok, this is embarassing. Well, note that this was written
(by me) for a specific target architecture, and never expected to be
portable. This little piece of work was called from
/* Function: horrible_noreturn_hack
If the return address points to the first instruction of a function,
decrement the return address by one instruction. */
iq2000_horrible_noreturn_hack (struct frame_info *fi)
/* Some functions (notably those that are not expected to return)
seem to end with a jump_and_link instruction (plus a no-op).
When this happens, the return address seems to be the first
instruction of the next function. This messes up the backtrace.
I can think of no legitimate way that the return address
could actually be the first address of a function,
[NOTE: except for the entry point address for a call dummy],
so if we detect this, we'll decrement it by one instruction
(so that it hopefully points into the previous function). */
if (fi && fi->extra_info && fi->extra_info->frame_cached_pc)
if (get_pc_function_start (fi->extra_info->frame_cached_pc) ==
if (fi->extra_info->frame_cached_pc != entry_point_address ())
fi->extra_info->frame_cached_pc -= SIZEOF_IQ2000_INSN;
More information about the Gdb-patches