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

[Dmitry V. Levin]

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.

> 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.

> 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.


-- 
ldv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20180320/2d0013c4/attachment.bin>