This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC 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]

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


On Thu, 2005-08-18 at 07:06, Maciej W. Rozycki wrote:
>  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.

True.  Non-zero arguments really only work for some CISCs, like x86. 
But since x86 is one of the currently broken targets, we need to make
sure that when we fix it, that we don't also break non-zero counts here.

>   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.  

For any target using DWARF2, and which has proper frame info/unwind
info, debugging -fomit-frame-pointer code is not a problem.  This used
to be only a few targets, but nowadays it is most targets we really care
about.  So this isn't a good reason to accept any breakage here.

Also, as mentioned above, x86 is one of the targets that is currently
broken, and for which non-zero counts should work.  So this seems to
rule out solution 3, which gives the wrong result for non-zero counts on
x86.  And this seems to rule out solution 4, which leaves non-zero
counts unchanged, and hence still broken.

> 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.

Well, there is the problem of how to ensure that -fno-omit-frame-pointer
was used.  This is what solution 5 addresses, by disabling frame pointer
elimination in that case.

Otherwise, this issue is discussed a bit in messages from Andreas
Krebbel that I referred to.  The issue here is that for a non-zero
count, we must find the previous frame pointer at an offset from the
current frame pointer.  If we eliminate the frame pointer, then offsets
change, and there is no guarantee that we get the right result.  Thus,
for non-zero counts, it really works best if we do not eliminate the
frame pointer.  There is also the problem that the soft frame pointer
and the hard frame pointer may not have the same value, and hence, in
order to get the offsets right, we have to use the actual hard frame
pointer here.

For a zero count, as many have mentioned, we don't really care which
frame address we get, any one is as good as any other, so frame pointer
elimination isn't a problem, and using the soft frame pointer is OK.

So these arguments lead me to believe that solution 6 is the best
choice.
-- 
Jim Wilson, GNU Tools Support, http://www.specifix.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]