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/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? 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 <rol...@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, Ignacy -- Ignacy Gawędzki R&D Engineer Green Communications _______________________________________________ devel mailing list devel@uclibc-ng.org http://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel
