[PATCH 2/2] stack trace support: print full instruction pointer in addition to offset

[Thomas De Schampheleire]

Hi Masatake,

On Thu, Nov 6, 2014 at 5:55 PM, Masatake YAMATO <yamato at redhat.com> wrote:
> Hi,
>
> ...
>>  unwind.c |   18 +++++++++++++-----
>>  1 files changed, 13 insertions(+), 5 deletions(-)
>>
>> Note: I would find it more logical to only show the full instruction pointer,
>> instead of both the instruction pointer and the offset. But I'm not sure if
>> everyone would agree to that.
>>
>
> In any environment, can we exepct a library or execrable file is mapped to
> predictable address?
>
> I conducted a small test on my Fedora 20.
>
>     % for x in /proc/[0-9]*/exe; do if [ "$(readlink $x)" = /usr/bin/zsh ]; then echo $x; cat $(dirname $x)/maps | grep zutil.so | grep 'r-xp'; fi; done
>     /proc/10783/exe
>     7f19a06f0000-7f19a06f7000 r-xp 00000000 fd:02 726402                     /usr/lib64/zsh/5.0.7/zsh/zutil.so
>     /proc/14948/exe
>     7f3e9fbb2000-7f3e9fbb9000 r-xp 00000000 fd:02 726402                     /usr/lib64/zsh/5.0.7/zsh/zutil.so
>     /proc/16628/exe
>     7fc3968f9000-7fc396900000 r-xp 00000000 fd:02 726402                     /usr/lib64/zsh/5.0.7/zsh/zutil.so
>     /proc/17755/exe
>     7f693048c000-7f6930493000 r-xp 00000000 fd:02 726402                     /usr/lib64/zsh/5.0.7/zsh/zutil.so
>     /proc/21170/exe
>     7f568e5a3000-7f568e5aa000 r-xp 00000000 fd:02 726402                     /usr/lib64/zsh/5.0.7/zsh/zutil.so
>     /proc/26202/exe
>     7f5722623000-7f572262a000 r-xp 00000000 fd:02 726402                     /usr/lib64/zsh/5.0.7/zsh/zutil.so
>     /proc/26493/exe
>     7fa92bd2f000-7fa92bd36000 r-xp 00000000 fd:02 726402                     /usr/lib64/zsh/5.0.7/zsh/zutil.so
>     /proc/27923/exe
>     7fa92bd2f000-7fa92bd36000 r-xp 00000000 fd:02 726402                     /usr/lib64/zsh/5.0.7/zsh/zutil.so
>     /proc/30561/exe
>     7fc47df8e000-7fc47df95000 r-xp 00000000 fd:02 726402                     /usr/lib64/zsh/5.0.7/zsh/zutil.so
>     /proc/6957/exe
>     7f578b0bf000-7f578b0c6000 r-xp 00000000 fd:02 726402                     /usr/lib64/zsh/5.0.7/zsh/zutil.so
>     /proc/7633/exe
>     7f771db8e000-7f771db95000 r-xp 00000000 fd:02 726402                     /usr/lib64/zsh/5.0.7/zsh/zutil.so
>
> zutil.so used in zsh is mapped to different addresses process by process.
> That means, the pair of ip and library(or execrable file) name is not enough
> for resolving stack trace. Am I wrong?

No, you're absolutely right.
I was not properly considering shared libraries. These are compiled as
PIC (position-independent code), and are relocated at run-time. In
this case, you indeed need the true_offset to be able to decode.
For the main executable, no runtime relocation is performed, and to
decode addresses you need the full ip.

>
> However, if the address used in the mapping are statically defined, in
> other words, predictable, the full instruction pointer is enough.
>
> About the output format, I feel
>
>  > /bin/busybox() [0x10062c60]/[0x62c60]
>
> is a bit verbose in usage of brackets.
>
> How do you think one of following format?
>
>  > /bin/busybox() [0x10062c60|0x62c60]
>  > /bin/busybox() [0x10062c60/0x62c60]
>  > /bin/busybox() [0x10062c60:0x62c60]

Yes, I'm fine with such reduced format. Of the three you suggested, I
find the second version with / most readable.

Should I already rework with this change or wait for more feedback?

Thanks,
Thomas