On Tue, Oct 04, 2016 at 06:46:22AM +0200, thus spake Waldemar Brodkorb: > 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?
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 _______________________________________________ devel mailing list devel@uclibc-ng.org http://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel
