Re: __builtin_return_address for ARM
On Thu, 26 Feb 2009 15:54:14 + 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 N0 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 N0 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
Re: __builtin_return_address for ARM
On Fri, 27 Feb 2009 13:32:11 + Julian Brown jul...@codesourcery.com wrote: GLIBC already knows how to do backtracing if the ARM-specific unwind tables are present (.ARM.exidx, etc.), using _Unwind_Backtrace. I'm told this probably isn't true for upstream GLIBC -- but we definitely have a patch somewhere to make GLIBC backtrace use _Unwind_Backtrace, which we'll submit upstream in due course. Sorry for the misinformation! Cheers, Julian
Re: __builtin_return_address for ARM
Julian Brown wrote: On Thu, 26 Feb 2009 15:54:14 + 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 N0 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 N0 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. I was about to say On no it doesn't! but I read your subsequent email. :-) 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. Yeah, I noticed that when I implemented _Unwind_Backtrace. It didn't matter to me at the time because full unwind info is required for everything linked with gcj. Andrew.
Re: __builtin_return_address for ARM
Julian Brown wrote: 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. I don't understand this. Sorry if I'm being slow, but isn't it just a matter of returning instead of calling abort when the search for the parent frame's FDE fails in uw_update_context (or whatever it's called, didn't check)? Marking bits in the linker doesn't enable you to unwind past them somehow, does it? cheers, DaveK
Re: __builtin_return_address for ARM
Dave Korn wrote: Julian Brown wrote: 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. I don't understand this. Sorry if I'm being slow, but isn't it just a matter of returning instead of calling abort when the search for the parent frame's FDE fails in uw_update_context (or whatever it's called, didn't check)? Marking bits in the linker doesn't enable you to unwind past them somehow, does it? Err, no. We don't want to abort, but instead cleanly terminate the backtrace. ATM it can just go into an infinite loop. Andrew.
Re: __builtin_return_address for ARM
On Friday 27 February 2009, Dave Korn wrote: Julian Brown wrote: 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. I don't understand this. Sorry if I'm being slow, but isn't it just a matter of returning instead of calling abort when the search for the parent frame's FDE fails in uw_update_context (or whatever it's called, didn't check)? Marking bits in the linker doesn't enable you to unwind past them somehow, does it? ARM unwind tables are series of open ranges (only the start address is specified for each region). i.e. your assumption that the search will fail is incorrect. It will actually find the entry for the preceding function. The new linker bits automatically add cantunwind entries for code/objects that do not have unwind information. Paul
Re: __builtin_return_address for ARM
Paul Brook wrote: ARM unwind tables are series of open ranges (only the start address is specified for each region). i.e. your assumption that the search will fail is incorrect. It will actually find the entry for the preceding function. The new linker bits automatically add cantunwind entries for code/objects that do not have unwind information. I see, thanks (and Andrew); this is a platform-specific quirk of the file format. cheers, DaveK
Re: __builtin_return_address for ARM
As I understand it, the ARM kernel can now do something similar. So, the only use for a __builtin_return_address(N) that used the frame pointer chain would be if the code were compiled with nonstandard options. Correct. Well, but wouldn't it still be nice if __builtin_return_address(N) was implemented for N0 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 N0 much less so. Paul
Re: __builtin_return_address for ARM
Paul Brook wrote: As I understand it, the ARM kernel can now do something similar. So, the only use for a __builtin_return_address(N) that used the frame pointer chain would be if the code were compiled with nonstandard options. Correct. Well, but wouldn't it still be nice if __builtin_return_address(N) was implemented for N0 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 N0 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. Andrew.
Re: __builtin_return_address for ARM
Uwe Kleine-König wrote: Hello, currently[1] __builtin_return_address for ARM only works with level == 0. For ftrace in the linux kernel it would be great to implement that for level 0 (provided that framepointers or unwind information are available of course). On the linux-arm-kernel ML Mikael Pettersson[2] said that __builtin_return_address(N) where N0 should never have been introduced into gcc.. Is that the general view for __builtin_return_address or would a patch be accepted? My personal opinion is that Mikael Pettersson is right, but since the damage is done why not extend it to more architectures. I am not an ARM maintainer though. Paolo
Re: __builtin_return_address for ARM
Uwe Kleine-König wrote: currently[1] __builtin_return_address for ARM only works with level == 0. For ftrace in the linux kernel it would be great to implement that for level 0 (provided that framepointers or unwind information are available of course). On the linux-arm-kernel ML Mikael Pettersson[2] said that __builtin_return_address(N) where N0 should never have been introduced into gcc.. Is that the general view for __builtin_return_address or would a patch be accepted? The old APCS, if I recall correctly, required a frame pointer, so __builtin_return_address(N) was easy. Up to now I only had a quick glance at gcc sources and after that I'm not sure if I even find the place where to put an implementation, so any help is welcome. In userland ARM EABI doesn't have a frame pointer chain, so what you suggest isn't possible. However, we do need to unwind the stack so we use the unwinder info. For this you have to call _Unwind_Backtrace directly. As I understand it, the ARM kernel can now do something similar. So, the only use for a __builtin_return_address(N) that used the frame pointer chain would be if the code were compiled with nonstandard options. Andrew.
Re: __builtin_return_address for ARM
On Wednesday 25 February 2009, Andrew Haley wrote: Uwe Kleine-König wrote: currently[1] __builtin_return_address for ARM only works with level == 0. For ftrace in the linux kernel it would be great to implement that for level 0 (provided that framepointers or unwind information are available of course). On the linux-arm-kernel ML Mikael Pettersson[2] said that __builtin_return_address(N) where N0 should never have been introduced into gcc.. Is that the general view for __builtin_return_address or would a patch be accepted? The old APCS, if I recall correctly, required a frame pointer, so __builtin_return_address(N) was easy. One minor exception: Thumb code generally doesn't have a frame pointer chain either, even on old-abi targets. In general it's impossible to make __builtin_return_address(N) to work for N0. Up to now I only had a quick glance at gcc sources and after that I'm not sure if I even find the place where to put an implementation, so any help is welcome. In userland ARM EABI doesn't have a frame pointer chain, so what you suggest isn't possible. However, we do need to unwind the stack so we use the unwinder info. For this you have to call _Unwind_Backtrace directly. As I understand it, the ARM kernel can now do something similar. So, the only use for a __builtin_return_address(N) that used the frame pointer chain would be if the code were compiled with nonstandard options. Correct. The short story is that on modern ARM targets[1] there is no standard frame layout. It is not possible to do backtraces without using additional unwind tables. Current arm-linux kernels use a special set of options to allow this under most circumstances. However this often incurs a significant performance and code size hit, and isn't supported at all when you switch to Thumb mode. Paul [1] I believe the same is also true for some other targets, e.g. MIPS.
Re: __builtin_return_address for ARM
On Wed, 2009-02-25 at 12:27 +, Paul Brook wrote: In general it's impossible to make __builtin_return_address(N) to work for N0. In any situation where you need to look beyond the current frame needs agreement as to how the data required can be found. That's going to have an impact somehow compared with not permitting such access (if a compiler knows that its frame is private then it can make all kinds of optimizations that would be unacceptable otherwise). There are essentially two ways of exposing the information needed here: 1) You can lay out every frame according to an agreed model 2) You can provide every frame with a description that can be interpreted to recover the required information. Neither is free. Case 1 is the worst since it severely impacts performance for code even if it never makes use of your feature. Case 2 is less bad in performance terms, but has a major impact on space in that the descriptions can be non-trivial. IMO any solution based on case 1 is unacceptable -- why should I penalise my code for some feature that you want, but I'm completely uninterested in? Case 2 is only acceptable if constructed in such a way that the additional information can be automatically discarded if it is not required -- again, why should I penalise my code size numbers for a feature I don't want. In statically linked images it might be possible to determine that the additional unwind information is unneeded and simply throw it away during linking, but you can't do that in a shared library environment, so we're back to the original sticking point: who gave you the right to impose such a levy on my code? Finally, gcc for ARM conforms to the ABI for the ARM Architecture -- that says what can and can't be assumed when linking code built from other tool chains. If you want a feature like this to work you'll need to persuade the other toolchain developers to co-operate -- I think they are extremely unlikely to be interested R.
Re: __builtin_return_address for ARM
Paul Brook wrote: On Wednesday 25 February 2009, Andrew Haley wrote: In general it's impossible to make __builtin_return_address(N) to work for N0. In userland ARM EABI doesn't have a frame pointer chain, so what you suggest isn't possible. However, we do need to unwind the stack so we use the unwinder info. For this you have to call _Unwind_Backtrace directly. As I understand it, the ARM kernel can now do something similar. So, the only use for a __builtin_return_address(N) that used the frame pointer chain would be if the code were compiled with nonstandard options. Correct. Well, but wouldn't it still be nice if __builtin_return_address(N) was implemented for N0 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? cheers, DaveK
