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

[Dmitry V. Levin]

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.


-- 
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/433b4814/attachment.bin>