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? > 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 <[email protected]> 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 _______________________________________________ devel mailing list [email protected] http://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel
