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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
15 matches
Mail list logo
