6 Oct
2016
6 Oct
'16
9:40 a.m.
On Tue, Oct 04, 2016 at 06:46:22AM +0200, thus spake Waldemar Brodkorb:
Hi Ignacy,
Ignacy Gawędzki wrote,
This is much more complicated than it seems. I tried to sync the code
with glibc but that turned out to have too many implications. The
idea behind the glibc code is twofold. First, the prototype for
__gcc_personality_v0 is kept in a macro which has a generic definition
in sysdeps/generic/unwind-resume.h and an ARM-specific one in
sysdeps/arm/unwind-resume.h. Second, the generic implementation of
_Unwind_Resume in both unwind-resume.c and unwind-forcedunwind.c is
included only on the condition that there is no arch-specific version.
The ARM-specific version is implemented directly in assembly.
Using the assembly source makes not much sense because it requires
some macros which are missing in uClibc-ng and others that require a
test at configuration-time. So I figured we can use the C source with
inline assembly just as well.
Currently I struggle with the integration of all this in the existing
makefiles. There are tons of variables defined with no documentation
whatsoever to guide me in the process.
In glibc it seems there are two places where the code from
unwind-resume is needed, that is libc and librt which are compiled
with -fexceptions and use cleanup functions. That code offers an
implementation of _Unwind_Resume and __gcc_personality_v0. The code
from unwind-forcedunwind is needed in libpthread and offers an
implementation of _Unwind_Resume and __gcc_personality_v0 along with
_Unwind_ForcedUnwind, _Unwind_GetCFA, etc. So basically, whenever
_Unwind_Resume or __gcc_personality_v0 is required in libc or librt,
the implementation from unwind-resume is used, whereas in libpthread,
it's the one from unwind-forcedunwind which is used.
In uClibc-ng, since the integration of librt and libpthread in libc,
the only included implementation is from unwind-forcedunwind, which
should basically just work (except that it needs a special
implementation of _Unwind_Resume for ARM). I don't know if there's a
way to make code in libc and librt call one implementation (from
unwind-resume) and code in libpthread call the other
(unwind-forcedunwind). If you agree that it's impossible or too
twisted to be worth it, I propose to diverge from glibc and remove
unwind-resume altogether.
In any case, I would greatly appreciate some help regarding the way to
modify the makefiles.
Cheers,
Ignacy
--
Ignacy Gawędzki
R&D Engineer
Green Communications
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? 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:
> 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? 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,