4 Oct
2016
4 Oct
'16
4:46 a.m.
Hi Ignacy,
Ignacy Gawędzki wrote,
On Mon, Oct 03, 2016 at 06:13:45PM +0200, thus spake
Waldemar Brodkorb:
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.
Thanks, now i understand. Could you create a patch and sync the
code?
best regards
Waldemar
Hi Ignacy,
Ignacy Gawędzki wrote,
Yes, it looks like it does. But at least _Unwind_Resume doesn't seem
to be used at all.
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:
> 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.
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
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).
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?
Yes it is.
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.
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 with you that the code should sync with glibc's as much as
possible in this regard, since the problem is exactly the same.
Cheers,