[RFC] Unexpected automatic language switch - get_frame_language()

Michael Snyder msnyder@redhat.com
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.  */

static void
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 mailing list