Richard Sandiford wrote: > Mark Mitchell <[EMAIL PROTECTED]> writes: >> I'd suggest we leave backtrace() aside, and just talk about >> __builtin_frame_address(0), which does have well-defined semantics. >> _b_f_a(0) is currently broken on ARM, and we all agree we should fix it. > > I don't want to fan the flames here, but I'm not sure either statement > is true. Does __builtin_frame_address(0) really have well-defined > semantics on a target for which the ABI does not specify a frame layout? > I think that's Richard's point.
Thanks for explaining; after the latest messages from you and Richard E., I understand the ARM doesn't have a standard frame layout. I had not realized that before. However, even though there's not an ARM ABI layout, if GCC uses a standard layout, then it would make sense for _b_f_a(0) to return a pointer to that frame. (_b_f_a(0) is a GCC extension, so it can have a GCC-specific definition.) If even that condition does not hold, then I agree that _b_f_a(0) should just have undefined behavior on ARM. We might even consider making it an error to use it. We should document in the manual that you can't use _b_f_a(0) on reliably on some architectures. If, however, there are plausible semantics we like for _b_f_a(0) on ARM, then it doesn't seem to me that we should worry terribly much about pessimizing the code by requiring a hard frame pointer. Of course, it would be better not to do so -- but if the only functions affected are those that actually call _b_f_a(0), I doubt we'd be able to measure a change in any real-world program. Richard E. asked what possible uses this function might have. Obviously, GLIBC's backtrace() function is one, though I guess that's a weak example, in that we all agree one should really be using unwind information. (I still think it's somewhat valid, in that there are a lot of people building GCC-only applications, and if backtrace() worked in that case, it would be better than not working at all.) The other examples I can think of are also odd hacks; for example, checking for stack overwrites, manually poking ones own return address pointer, or manually grabbing saved registers from a caller, or some such. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
