Re: [RFC] PowerPC prologue unwinder / epilogue detection improvements

[Thiago Jung Bauermann <bauerman at br dot ibm dot com>]

(Leaving a lot of the context since this e-mail is from so long ago.)

El jue, 06-12-2007 a las 16:41 -0500, Daniel Jacobowitz escribiÃ:
> The patch also contains two things that are not straightforward and I
> am not going to commit as they are:
> 
>   - Both the oldish MontaVista toolchain their customer was using, and
>   the Debian Sarge toolchain on the test machine I used for the port
>   to HEAD GDB, are built with GCC 3.4.  There's an annoying bug in
>   this version of GCC.  Given a sequence like this:
> 
>        stwu    r1,-48(r1)
>        mflr    r0
>        bl      0x26384
>        stw     r0,52(r1)
>        ...
> 
>   GCC will not report the move of the return address from LR to r0.
>   It leaves the return address column pointing at LR until the end of
>   the prologue, and then updates it to point directly at 52(r1) on the
>   stack.
> 
>   I forcibly detect this case in the patch below and use the prologue
>   unwinder instead of the DWARF-2 unwinder if the prologue contains a
>   bl instruction (-fpic or -fPIC).  This is much too heavy-handed.  Is
>   it worth working around this bug in GDB?
> 
>   If so, we should find a way to limit it to some likely selection of
>   GCC-generated objects.  If not - my inclination is not - I'll simply
>   drop this part of the patch.  Anyone who needs it can find it in the
>   list archives.

This is not a problem which affects me, but I wonder:

Is it an option to look at the DW_AT_producer for the CU in question and
enable the hack only for GCC 3.4? If there's no .debug_info section
available, then oh well, we tried...
-- 
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center