Re: [uclibc-ng-devel] [RFC PATCH v2 0/1] libpthread/nptl: Use arch-dependent unwind-forcedunwind.c if available

[Ignacy Gawędzki]

On Tue, Oct 04, 2016 at 06:46:22AM +0200, thus spake Waldemar Brodkorb:
> Hi Ignacy,
> Ignacy Gawędzki wrote,
> 
> > On Mon, Oct 03, 2016 at 06:13:45PM +0200, thus spake Waldemar Brodkorb:
> > > Hi Ignacy,
> > > Ignacy Gawędzki wrote,
> > > 
> > > > On Mon, Oct 03, 2016 at 12:26:19PM +0200, thus spake Ignacy Gawedzki:
> > > > > On Sat, Oct 01, 2016 at 01:22:37PM +0200, thus spake Waldemar 
> > > > > Brodkorb:
> > > > > > Can you please try with 1.0.18? I can not reproduce the issue with
> > > > > > 1.0.18.
> > > > > > 
> > > > > > I just get "caught" with the test app.
> > > > > > 
> > > > > > May be it was accidentally fixed in the release.
> > > > > 
> > > > > I don't get the uncaught exception with 1.0.18 indeed.  This is
> > > > > certainly due to the way libpthread is now integrated into libc.  Now
> > > > > the version of Unwind_Resume that is called is always the one from
> > > > > libgcc_1.so, even when using threads.  I'm affraid that this is not
> > > > > the right thing to do, because the wrapping code for Unwind_Resume in
> > > > > libpthread was there for some reason.
> > > > 
> > > > Okay, I've explored that problem a bit more today and I have
> > > > additional information.  It seems that the Unwind_* functions are
> > > > provided in the libc for local use and are not supposed to be visible
> > > > for the dynamic linker.  Compare that with GNU libc where the Unwind_*
> > > > symbols are local.
> > > > 
> > > > Right now it also seems that none of uClibc's code actually uses these
> > > > functions, at least in my case, so the incorrect Unwind_Resume inside
> > > > uClibc is harmless.
> > > 
> > > But isn't pthread_cancel using pthread_cancel_init from
> > > libpthread/nptl/sysdeps/pthread/unwind-forcedunwind.c?
> > 
> > Yes, it looks like it does.  But at least _Unwind_Resume doesn't seem
> > to be used at all.
> > 
> > > > The problem I was having with v1.0.17 was that by linking with
> > > > libpthread, the Unwind_Resume wrapper code in that library was
> > > > overriding the implementation in libgcc_s that was supposed to be
> > > > called directly.
> > > 
> > > I still do not understand the issue.
> > > As far as I know, the Unwind* functions in uClibc and GNU libc is
> > > wrapper code around gcc libgcc_s.so.1 which is loaded via dlopen
> > > at runtime.
> > 
> > Yes, they are, but the problem is with the way the ARM unwinder works.
> > Obviously, it doesn't expect to have one additional frame added by a
> > call to _Unwind_Resume.  This is why in the case of the ARM
> > architecture, a specially-crafted version of the wrapper around
> > _Unwind_Resume is provided which doesn't create a new frame.
> > 
> > > I once asked about this on the libc mailinglist:
> > > https://sourceware.org/ml/libc-help/2014-07/msg0.html
> > >  
> > > > Now that libpthread (and librt for that matter) are integrated into
> > > > libc, it seems the problem is gone, because the libgcc_s
> > > > implementation is not overridden by uClibc's.  But this happens only
> > > > because libgcc_s.so is listed before libc.so in the .dynamic section,
> > > > and if it were not the case anymore, for any reason, the problem would
> > > > reemerge immediately.
> > > > 
> > > > You can force the problem to re-emerge by simply preloading libc.so
> > > > using LD_PRELOAD.  This makes uClibc's incorrect implementation of
> > > > Unwind_Resume to be called and the execution of the example code
> > > > aborts instead of outputting "caught".
> > > > 
> > > > Please find attached the updated patch for v1.0.18.  This is more like
> > > > a quick fix, since a proper fix would most probably be to make those
> > > > conflicting symbols local in the resulting .so.
> > > 
> > > But what exactly is fixed by the patch then?
> > 
> > The patch makes _Unwind_Resume in libpthread/nptl/ be implemented by
> > sysdeps/unix/sysv/linux/arm/unwind-forcedunwind.c in the case of ARM
> > and by sysdeps/pthread/unwind-forcedunwind.c otherwise.  So if
> > libc.so's _Unwind_Resume ever takes over libgcc_s.so's, or if the
> > wrapper around _Unwind_Resume is used in the future, it will simply
> > work transparently.
> > 
> > The way this is achieved is inspired by how it's already done for
> > librt with unwind-resume.c (see sysdeps/pthread/rt-unwind-resume.c).
> > 
> > > Is it still a ARM specific issue?
> > 
> > Yes it is.
> > 
> > > Could you take a look at glibc commit:
> > > commit 46abb64d6287d09100b147d062f6810066389b7e
> > > Author: Roland McGrath 
> > > Date:   Mon Jan 5 14:01:49 2015 -0800
> > > 
> > > ARM: Consolidate with generic unwinder wrapper code
> > > 
> > > I think it would be a better solution to sync with glibc and
> > > get rid of the special ARM specific versions.
> > 
> > I you look closely at this commit, it's exactly what I'm talking
> > about: it's providing an ARM-specific implementation of _Unwind_Resume
> > in assembly.  For other architectures, the generic wrapper is used.
> > 
> > Now I agree 

[uclibc-ng-devel] [RFC PATCH v2 0/1] libpthread/nptl: Use arch-dependent unwind-forcedunwind.c if available

[Ignacy Gawędzki]

On Mon, Oct 03, 2016 at 12:26:19PM +0200, thus spake Ignacy Gawedzki:
> On Sat, Oct 01, 2016 at 01:22:37PM +0200, thus spake Waldemar Brodkorb:
> > Can you please try with 1.0.18? I can not reproduce the issue with
> > 1.0.18.
> > 
> > I just get "caught" with the test app.
> > 
> > May be it was accidentally fixed in the release.
> 
> I don't get the uncaught exception with 1.0.18 indeed.  This is
> certainly due to the way libpthread is now integrated into libc.  Now
> the version of Unwind_Resume that is called is always the one from
> libgcc_1.so, even when using threads.  I'm affraid that this is not
> the right thing to do, because the wrapping code for Unwind_Resume in
> libpthread was there for some reason.

Okay, I've explored that problem a bit more today and I have
additional information.  It seems that the Unwind_* functions are
provided in the libc for local use and are not supposed to be visible
for the dynamic linker.  Compare that with GNU libc where the Unwind_*
symbols are local.

Right now it also seems that none of uClibc's code actually uses these
functions, at least in my case, so the incorrect Unwind_Resume inside
uClibc is harmless.

The problem I was having with v1.0.17 was that by linking with
libpthread, the Unwind_Resume wrapper code in that library was
overriding the implementation in libgcc_s that was supposed to be
called directly.

Now that libpthread (and librt for that matter) are integrated into
libc, it seems the problem is gone, because the libgcc_s
implementation is not overridden by uClibc's.  But this happens only
because libgcc_s.so is listed before libc.so in the .dynamic section,
and if it were not the case anymore, for any reason, the problem would
reemerge immediately.

You can force the problem to re-emerge by simply preloading libc.so
using LD_PRELOAD.  This makes uClibc's incorrect implementation of
Unwind_Resume to be called and the execution of the example code
aborts instead of outputting "caught".

Please find attached the updated patch for v1.0.18.  This is more like
a quick fix, since a proper fix would most probably be to make those
conflicting symbols local in the resulting .so.

Cheers,

Ignacy

Ignacy Gawędzki (1):
  libpthread/nptl: Use arch-dependent unwind-forcedunwind.c if available

 libpthread/nptl/sysdeps/pthread/Makefile.in   | 7 +--
 libpthread/nptl/sysdeps/pthread/pthread-unwind-forcedunwind.c | 1 +
 2 files changed, 6 insertions(+), 2 deletions(-)
 create mode 100644 
libpthread/nptl/sysdeps/pthread/pthread-unwind-forcedunwind.c

-- 
2.7.4

___
devel mailing list
devel@uclibc-ng.org
http://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel