|
From: Tom H. <to...@co...> - 2005-11-04 11:36:51
|
In message <17018.194.109.230.85.1131099944.squirrel@194.109.230.85>
Jeroen N. Witmond <jn...@xs...> wrote:
> In blanket, when I use tl_assert(false) or VG_(tool_panic)("Text") I get a
> stack trace without function name, source file and line number
> information:
>
> Blanket: the 'impossible' happened:
> Cannot determine order of keys: 4000C22:4000C27 <=> 4000C20:4000C22
> ==6748== at 0xB00015DA: ???
> ==6748== by 0xB00015D9: ???
> [11 similar lines removed]
>
> Module .in_place/blanket does contain debugging information, so `readelf
> -w` tells me. I cannot find an open bug report for this problem. Can
> anybody shed some light on this?
No idea I'm afraid - it seems to work for me on x86 systems with
a tl_assert call inserted in nl_instrument in the none tool.
There are some issues on amd64 - one I have just committed a fix
for but the other is more complicated.
The second issue is that when report_and_quit gets the initial
context it does this:
ip = (Addr)__builtin_return_address(0);
GET_REAL_SP_AND_FP(sp, fp);
The problem is that by doing that we get the return address (which
is in the calling function) but the current functions stack and frame
pointers which means that a CFI unwind fails because it looks up the
calling function's CFI data and tries to adjust the SP to get the
address of the CFA but as the SP value is bogus it doesn't find it
and the unwind fails.
As there is no reliable/easy way to get the calling functions stack
and frame pointers my best fix at the moment is to use the current
value of the PC instead of the return address. A patch for that is
attached which works on x86/amd64 but needs a small assembly tweak
for ppc32 to get the PC value.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|