Re: [PATCH] Incorrect code for __builtin_frame_address(0)

["Maciej W. Rozycki" <macro at linux-mips dot org>]

On Wed, 17 Aug 2005, James E Wilson wrote:

> This leads to the following possible solutions
> 1) Add machine dependent definitions of INITIAL_FRAME_ADDRESS_RTX to all
> ports other than s390.
> 2) Define INITIAL_FRAME_ADDRESS_RTX to frame_pointer_rtx in a few ports.
>  Or perhaps all other than s390.
> 3) Default INITIAL_FRAME_ADDRESS_RTX to frame_pointer_rtx.
> 4) Default INITIAL_FRAME_POINTER_RTX to frame_pointer_rtx only if the
> count is 0.
> 5) Disable frame pointer elimination if INITIAL_FRAME_POINTER_RTX is not
> defined.
> 6) Use 4 if count == 0, and 5 otherwise.
> 
> Solution 1 is impractical.  Andreas Krebbel claims that solutions 2 and
> 3 will break support for count != 0.  I haven't tried looking at this
> myself, but the argument looks credible.  Solution 4 looks good, except
> that it leaves the count != 0 case broken.  Solution 5 is safe, and easy
> to implement, but disables optimization unnecessarily for the count == 0
> case.  Solution 6 is less safe, but avoids the optimization loss except
> when count != 0, which will be rare, and hence seems like the best
> choice.  The main problem with this choice is that it is harder to write
> the docs for the INITIAL_FRAME_POINTER_RTX macro.

 Note that documentation for __builtin_return_address() and 
__builtin_frame_address() explicitly states:

    "This function should only be used with a nonzero argument for
     debugging purposes."

and also suggests non-zero arguments may actually never work for some 
machines.  And then for "-fomit-frame-pointer":

    "*It also makes debugging impossible on some machines.*"

so I think solutions 3 and 4 are good trade-offs.  Solution 5 only seems 
reasonable together with one of 1 - 4; consequently that applies to 6 as 
well.  I can't see a reason for solutions 2 and 3 not to work for count != 
0 for "-fno-omit-frame-pointer" as they only affect figuring out the frame 
pointer at level 0, but perhaps I'm missing something.  Implementing 
solution 1 may be tedious, but I guess it mostly reduces to solution 2, 
perhaps except from some arcane ABIs.

  Maciej