[PATCH 6/9] unwind: allow to specify unwinder back-end with -k option

[Masatake YAMATO]

On Tue, 20 Mar 2018 21:39:43 +0300, "Dmitry V. Levin" <ldv at altlinux.org> wrote:
> On Wed, Mar 21, 2018 at 03:17:31AM +0900, Masatake YAMATO wrote:
>> On Tue, 20 Mar 2018 20:55:53 +0300, "Dmitry V. Levin" <ldv at altlinux.org> wrote:
>> > On Wed, Mar 14, 2018 at 02:28:11AM +0900, Masatake YAMATO wrote:
>> >> With this commit, -k option can take an optional argument
>> >> specifying unwinder like:
>> >> 
>> >>   $ strace -klibunwind ...
>> >> 
>> >> Here, "libunwind" is the name of unwinder. Currently only libunwind
>> >> is available as unwinder. Using libdw as unwinder is planed.
>> >> 
>> >> If no unwinder is given, strace choose one of available unwinders
>> >> linked in the build time.
>> > 
>> > Given that libdw already performs better than libunwind as unwinder, why
>> > would one want to build a strace executable that supports both unwinders
>> > simultaneously?
>> 
>> I myself don't have much strong reason supporting both.
>> 
>> However, I guess there are not a few people who want
>> not to link GPL'ed library to strace. (I myself like GPL.)
> 
> Assuming that libdw is distributed under "LGPLv3+ or GPLv2+" license,
> linking with libdw shouldn't raise any issues at all.

Yes. Just using the word "GPL'ed" is my bad.
I don't have any more comments about this.

>> If both unwinders are supported, we can know a bug by comparing
>> outputs. libdw looks better but having the way to compare the result
>> easily is not bad.
> 
> I'm afraid that if strace executable would support both unwinders
> simultaneously and their output will be different in most cases,
> it would be a source of confusion rather than a useful
> debugging mechanism.

I see.

>> Splitting frontend (unwind.c) and backends (unwind-libdw.c and
>> unwind-libunwind.c) makes us improving the frontend easier because
>> unwind.c is so small than before.
> 
> The split itself is fine.

Thank you. I'm happy to hear this.

Though I have not studied yet but /usr/include/libunwind-dynamic.h
looks interesting. I wonder I can do something interesting in strace
with it.

However, as far as the frontend and the backend are splited well,
reintroducing the libunwind based backend is quite easy.

So I have no reason to object removing libunwind support from
strace.

I'm still working on v2 patch set. I will put a patch removing
libunwind support at the end of the patch set if you ask me.

Masatake YAMATO
> 
> -- 
> ldv