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

[Masatake YAMATO]

On Tue, 20 Mar 2018 22:53:34 +0300, "Dmitry V. Levin" <ldv at altlinux.org> wrote:
> On Wed, Mar 21, 2018 at 03:50:06AM +0900, Masatake YAMATO wrote:
>> 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.
> 
> Well, I do not suggest to remove libunwind support from strace yet.
> All I suggest is not to introduce *simultaneous* support of two different
> unwinders by a single strace executable.  Let -k option remain just
> a single option without arguments.

Oh, I see.
I will do so in the v2 patch set.

Masatake YAMATO

> 
> -- 
> ldv