> On Nov 21, 2021, at 8:28 AM, Jason Thorpe <thor...@me.com> wrote:
>
> If strip removes it, then you’re doomed anyway and trampoline assist via a
> function won’t help you, because you won’t be able to get to the trampoline
> or past it anyway.
Here’s a before/after of a “strip -s” of a binary on the DWARF unwind
information:
12 .eh_frame_hdr 000001a4 00000001200077f0 00000001200077f0 000077f0 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
13 .eh_frame 000007a4 0000000120007998 0000000120007998 00007998 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
12 .eh_frame_hdr 000001a4 00000001200077f0 00000001200077f0 000077f0 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
13 .eh_frame 000007a4 0000000120007998 0000000120007998 00007998 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
I.e. strip does not effect the unwind information, because unwind information
is not debugging information nor is it part of the symbol information; it is,
in fact, required for correct operation of the program in the face of
exceptions. And my test program still works:
alpha-vm:thorpej 22$ ./test1
^Cx 2
Backtrace 4 stack frames.
0x1200014e4 <_init+0x304> at ./test1
0x3fffdddbfd4 <__sigtramp_siginfo_2> at /usr/lib/libc.so.12
0x1200015e4 <_init+0x404> at ./test1
0x120001590 <_init+0x3b0> at ./test1
As you can see, because I stripped the symbols out of the program binary, the
symbol names are wrong, but the unwind works and the program counter values are
the same as an un-stripped copy of the program:
alpha-vm:thorpej 23$ ./sigbttest
^Cx 2
Backtrace 4 stack frames.
0x1200014e4 <handler+0x54> at ./sigbttest
0x3fffdddbfd4 <__sigtramp_siginfo_2> at /usr/lib/libc.so.12
0x1200015e4 <the_loop+0x1c> at ./sigbttest
0x120001590 <main+0x48> at ./sigbttest
So, I think your worry about it is unwarranted.
>> On Nov 21, 2021, at 7:54 AM, John Marino (NetBSD) <net...@marino.st> wrote:
>>
>>
>> I'm not very familiar with CFA information. I've been worried that strip(1)
>> removes those symbols. Is that worry meritless?
-- thorpej