3 Oct
2016
3 Oct
'16
4:13 p.m.
Hi Ignacy,
Ignacy Gawędzki wrote,
On Mon, Oct 03, 2016 at 12:26:19PM +0200, thus spake
Ignacy Gawedzki:
But isn't pthread_cancel using pthread_cancel_init from
libpthread/nptl/sysdeps/pthread/unwind-forcedunwind.c?
On Sat, Oct 01, 2016 at 01:22:37PM +0200, thus
spake Waldemar Brodkorb:
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. 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. 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.
I once asked about this on the libc mailinglist:
https://sourceware.org/ml/libc-help/2014-07/msg00000.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?
Is it still a ARM specific issue?
Could you take a look at glibc commit:
commit 46abb64d6287d09100b147d062f6810066389b7e
Author: Roland McGrath <roland(a)hack.frob.com>
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.
best regards
Waldemar