Re: Keep local symbols of rump libraries

[Ryota Ozaki <ozaki-r%netbsd.org@localhost>]

On Wed, Apr 12, 2017 at 6:58 PM, Ryota Ozaki <ozaki-r%netbsd.org@localhost> wrote:
> On Wed, Apr 12, 2017 at 9:27 AM, Chuck Silvers <chuq%chuq.com@localhost> wrote:
>> On Mon, Apr 10, 2017 at 07:22:45PM +0900, Ryota Ozaki wrote:
>>> Hi,
>>>
>>> I'm using ATF tests running rump kernels (rump_server)
>>> for development and debugging. When a rump kernel gets
>>> panic, it dumps a core file from which we can obtain
>>> a backtrace by using gdb.
>>>
>>> Unfortunately local symbols (i.e., static functions)
>>> in a backtrace are unresolved because they are stripped
>>> by the linker (and objdump). That makes debugging a bit
>>> difficult.
>>>
>>> The patch introduces a compile option for rump kernels
>>> called RUMP_KEEPSYMBOLS to keep such symbols:
>>>   http://www.netbsd.org/~ozaki-r/rumplibs-keep-symbols.diff
>>>
>>> The option is disabled by default to not increase
>>> the size of all rump libraries.
>>>
>>> I'm not so familiar with the NetBSD build system and
>>> Makefiles, so the patch may be wrong or clumsy.
>>>
>>> Any comments?
>>
>> I've been meaning to ask about something similar to this
>> but for everything in the build (libraries and commands)
>> for the benefit of dtrace.  dtrace "ustack()" stack traces
>> are similarly less useful without the static symbols.
>>
>> my patch for that was similar to yours, but I changed the
>> "-Wl,-x" to "-Wl,-X" rather than removing the option entirely.
>> for OBJCOPYLIBFLAGS I did what you did, though I suppose using "-X"
>> there too would have been more consistent.
>
> Sure. Changing -x to -X works for me.
>
>>
>> if we had an option for preserving static symbols for everything,
>> would you still want a rump-library-specific option?
>
> If it's useful for other than rump libraries, having a new global
> option would be adequate. I don't have an idea of the name though.

http://www.netbsd.org/~ozaki-r/libs-keep-symbols.diff

So this is a new patch that provides a global option named MKSTRIPSYM.
(the name is suggested by paulg, thanks!)

  ozaki-r