On Thu, 26 Feb 2009 15:54:14 +0000 Andrew Haley <a...@redhat.com> wrote:
> Paul Brook wrote: > >> Well, but wouldn't it still be nice if > >> __builtin_return_address(N) was implemented for N>0 by libcalling > >> into the unwinder for you? Obviously this would still have to > >> return NULL at runtime when you're running on a DW2 target without > >> any EH frame data present in memory (and I guess it wouldn't work > >> on SjLj targets either), but wouldn't it still be a nice > >> convenience feature for users? > > > > There are sufficiently many caveats and system specific bits of > > weirdness that you probably just have to know what you're doing (or > > rely on backtrace(3) to do it for you). > > > > IMHO builtins are for things that you can't do in normal C. So > > __builtin_return_address(0) makes a lot of sense. Having it start > > guessing how to do N>0 much less so. > > I suggest we could contribute a version of backtrace.c for ARM to > glibc. An example to follow is libc/sysdeps/ia64/backtrace.c. GLIBC already knows how to do backtracing if the ARM-specific unwind tables are present (.ARM.exidx, etc.), using _Unwind_Backtrace. Unfortunately backtraces don't currently terminate cleanly if code without unwind data is reached: CodeSourcery are currently working on fixing the linker so that non-unwindable regions are marked properly, which we consider essential to making this feature usable. Of course, you'll need to compile all your code with -funwind-tables for this to work. We haven't measured the size impact of this yet: we're planning on optimising the unwind tables by merging duplicate entries whenever possible, so hopefully it won't be too bad. Just a heads-up to avoid duplicate effort! Cheers, Julian
