Hi Ignacy, Ignacy Gawędzki wrote, > 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,
Thanks, now i understand. Could you create a patch and sync the code? best regards Waldemar _______________________________________________ devel mailing list devel@uclibc-ng.org http://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel
