Re: SPARC, register renaming, __builtin_return_address

[Franz Sirl <Franz dot Sirl-kernel at lauterbach dot com>]

At 11:24 14.05.2001, Mark Mitchell wrote:
> >>>>> "Franz" == Franz Sirl <Franz.Sirl-kernel@lauterbach.com> writes:
>
>     Franz> At 01:50 14.05.2001, Mark Mitchell wrote:
>     >> - The manual explicitly documents __builtin_return_address
>     >> being guaranteed to return the correct value only when the
>     >> index is 0.
>     >>
>     >> Therefore, the test-case is semi-bogus.
>
>     Franz> Nope, cause if __builtin_return_address(n) with n>=1
>     Franz> doesn't work on a target, it has to return 0 and then the
>     Franz> comparisons in the testcase are valid.
>
>Nope, because it doesn't have to consistently do that.  There's
>nothing in the documentation that says that it couldn't do it for 1
>sometimes, but not other times.  That might make sense; maybe you
>can't unwind past optimized stack frames, for example.

Hehe, I thought you would argue that way. But if we do the way you say, we 
have to deal with the situation that b_r_a(1) sometimes works and sometimes 
not, depending on the surrounding code. This would probably mean to 
introduce a proper warning for the user during compilation, since this 
isn't like normal code which might change behaviour under optimization if 
the user isn't careful, this is a compiler builtin und I believe the user 
can expect it to work _uniformly_ under all circumstances. If not, we have 
to unambiguously document it that way and introduce a compilation time 
warning IMHO.

But I think that's not worth it, it's easy for the targets to either return 
0 if they don't support b_r_a(1) or force a valid stackframe otherwise. The 
whole purpose of the testcase is to test for uniform behaviour for b_r_a(1).

Franz.