Re: [git commit] libubacktrace: use -funwind-tables rather than -fexecptions
On 01/01/2012 0.10, Mike Frysinger wrote: > On Thursday 22 December 2011 13:19:22 Carmelo AMOROSO wrote: >> On 22/12/2011 15.30, Carmelo Amoroso wrote: >>> commit: >>> http://git.uclibc.org/uClibc/commit/?id=8a8434b367e0b94b9fda72c99f1c6467 >>> >>> 37725403 branch: >>> http://git.uclibc.org/uClibc/commit/?id=refs/heads/master >>> >>> For backtrace to work is enough to use -funwind-tables instead >>> of -fexceptions. >>> >>> Signed-off-by: Carmelo Amoroso >> >> Indeed, I'm wondering if -fasynchrous-unwind-tables should be >> used rather then funwind-tables. On my arh SH4 the generated code >> is exactly the same. I'm not expert of DWARF, neither gcc >> documentation regarding the differences between -fexceptions, >> -funwind-tables or -fasynchronous-unwind-tables helped me so >> much. >> >> someone else has clearer idea ? > > for backtrace, we just want unwind-tables, so using that over > -fexceptions is good (since we don't have to handle exceptions in > this code). as for the async vs non-async unwind-tables, i don't > know the answer to that. -mike Thanks Mike for your feedback. I've reported here below the extract from gcc manual. Reading it again, it seems to me that using -fasynchronous-unwind-tables is the best as it's purpose is actually to create the dwarf2 information, in the other two cases (-fexceptions or -funwind-tables) it seems to be a side effect. Make sense ? Cheers, Carmelo -fexceptions Enable exception handling. Generates extra code needed to propagate exceptions. For some targets, this implies GCC will generate frame unwind information for all functions, which can produce significant data size overhead, although it does not affect execution. If you do not specify this option, GCC will enable it by default for languages like C++ which normally require exception handling, and disable it for languages like C that do not normally require it. However, you may need to enable this option when compiling C code that needs to interoperate properly with exception handlers written in C++. You may also wish to disable this option if you are compiling older C++ programs that don't use exception handling. -funwind-tables Similar to -fexceptions, except that it will just generate any needed static data, but will not affect the generated code in any other way. You will normally not enable this option; instead, a language processor that needs this handling would enable it on your behalf. -fasynchronous-unwind-tables Generate unwind table in dwarf2 format, if supported by target machine. The table is exact at each instruction boundary, so it can be used for stack unwinding from asynchronous events (such as debugger or garbage collector). > > > > ___ uClibc-cvs mailing > list uclibc-...@uclibc.org > http://lists.busybox.net/mailman/listinfo/uclibc-cvs ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
[PATCH] libc: allow to backtrace out of abort call
Build raise and abort function with dwarf2 info by using -fasynchronous-unwind-tables to make backtrace() working across a call to abort. A scenario where it could be useful is within a signal handler that wants to dump a backtrace when catching some signal (i.e SIGABRT). Without having abort & raise built with DWARF2 information, it is not possible for the libgcc stack unwinder to walk through the call stack out of the abort/raise function. Impacts in terms of size are really limited Current textdata bss dec hex filename 164 0 0 164 a4 ./libpthread/nptl/sysdeps/unix/sysv/linux/raise.os 164 0 0 164 a4 ./libpthread/nptl/sysdeps/unix/sysv/linux/raise.oS 220 24 4 248 f8 ./libc/stdlib/abort.os With (-fasynchronous-unwind-tables) textdata bss dec hex filename 216 0 0 216 d8 ./libpthread/nptl/sysdeps/unix/sysv/linux/raise.os 216 0 0 216 d8 ./libpthread/nptl/sysdeps/unix/sysv/linux/raise.oS 280 24 4 308 134 ./libc/stdlib/abort.os Signed-off-by: Carmelo Amoroso --- libc/signal/Makefile.in|2 ++ libc/stdlib/Makefile.in|2 ++ .../sysdeps/unix/sysv/linux/Makefile.commonarch|2 ++ 3 files changed, 6 insertions(+), 0 deletions(-) diff --git a/libc/signal/Makefile.in b/libc/signal/Makefile.in index a7e3078..ed8598b 100644 --- a/libc/signal/Makefile.in +++ b/libc/signal/Makefile.in @@ -24,6 +24,8 @@ ifneq ($(strip $(ARCH_OBJS)),) CSRC-y := $(filter-out $(notdir $(ARCH_OBJS:.o=.c)),$(CSRC-y)) endif +CFLAGS-raise.c = -fasynchronous-unwind-tables + SIGNAL_DIR := $(top_srcdir)libc/signal SIGNAL_OUT := $(top_builddir)libc/signal diff --git a/libc/stdlib/Makefile.in b/libc/stdlib/Makefile.in index 73e5462..9e96f03 100644 --- a/libc/stdlib/Makefile.in +++ b/libc/stdlib/Makefile.in @@ -27,6 +27,8 @@ CSRC-$(if $(findstring yy,$(UCLIBC_HAS_FLOATS)$(UCLIBC_SUSV3_LEGACY)),y) += \ gcvt.c CSRC-$(UCLIBC_SUSV3_LEGACY) += mktemp.c +CFLAGS-abort.c = -fasynchronous-unwind-tables + # multi source stdlib.c CSRC-y += abs.c labs.c atoi.c atol.c strtol.c strtoul.c _stdlib_strto_l.c \ qsort.c qsort_r.c bsearch.c \ diff --git a/libpthread/nptl/sysdeps/unix/sysv/linux/Makefile.commonarch b/libpthread/nptl/sysdeps/unix/sysv/linux/Makefile.commonarch index e28cec2..b32bc9b 100644 --- a/libpthread/nptl/sysdeps/unix/sysv/linux/Makefile.commonarch +++ b/libpthread/nptl/sysdeps/unix/sysv/linux/Makefile.commonarch @@ -128,6 +128,8 @@ CFLAGS-timer_gettime.c = -I$(top_srcdir)librt -DIS_IN_librt CFLAGS-timer_routines.c = -I$(top_srcdir)librt -DIS_IN_librt CFLAGS-timer_settime.c = -I$(top_srcdir)librt -DIS_IN_librt +CFLAGS-raise.c = -fasynchronous-unwind-tables + CFLAGS-linux = -DNOT_IN_libc -DIS_IN_libpthread $(SSP_ALL_CFLAGS) CFLAGS-OMIT-libc_pthread_init.c = -DNOT_IN_libc -DIS_IN_libpthread -- 1.7.4.4 ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] libc: allow to backtrace out of abort call
On Jan 3, 2012 7:11 PM, "Carmelo AMOROSO" wrote: > > Build raise and abort function with dwarf2 info by using > -fasynchronous-unwind-tables to make backtrace() working across a > call to abort. > > A scenario where it could be useful is within a signal handler that > wants to dump a backtrace when catching some signal (i.e SIGABRT). > Without having abort & raise built with DWARF2 information, it is not > possible for the libgcc stack unwinder to walk through the call stack > out of the abort/raise function. > > Impacts in terms of size are really limited Please use busybox's incarnation of bloat-o-meter to report size changes in the future. Acked-by: Bernhard Reutner-Fischer > > Current > textdata bss dec hex filename >164 0 0 164 a4 ./libpthread/nptl/sysdeps/unix/sysv/linux/raise.os >164 0 0 164 a4 ./libpthread/nptl/sysdeps/unix/sysv/linux/raise.oS >220 24 4 248 f8 ./libc/stdlib/abort.os > > With (-fasynchronous-unwind-tables) > > textdata bss dec hex filename >216 0 0 216 d8 ./libpthread/nptl/sysdeps/unix/sysv/linux/raise.os >216 0 0 216 d8 ./libpthread/nptl/sysdeps/unix/sysv/linux/raise.oS >280 24 4 308 134 ./libc/stdlib/abort.os > > Signed-off-by: Carmelo Amoroso > --- > libc/signal/Makefile.in|2 ++ > libc/stdlib/Makefile.in|2 ++ > .../sysdeps/unix/sysv/linux/Makefile.commonarch|2 ++ > 3 files changed, 6 insertions(+), 0 deletions(-) > > diff --git a/libc/signal/Makefile.in b/libc/signal/Makefile.in > index a7e3078..ed8598b 100644 > --- a/libc/signal/Makefile.in > +++ b/libc/signal/Makefile.in > @@ -24,6 +24,8 @@ ifneq ($(strip $(ARCH_OBJS)),) > CSRC-y := $(filter-out $(notdir $(ARCH_OBJS:.o=.c)),$(CSRC-y)) > endif > > +CFLAGS-raise.c = -fasynchronous-unwind-tables > + > SIGNAL_DIR := $(top_srcdir)libc/signal > SIGNAL_OUT := $(top_builddir)libc/signal > > diff --git a/libc/stdlib/Makefile.in b/libc/stdlib/Makefile.in > index 73e5462..9e96f03 100644 > --- a/libc/stdlib/Makefile.in > +++ b/libc/stdlib/Makefile.in > @@ -27,6 +27,8 @@ CSRC-$(if $(findstring yy,$(UCLIBC_HAS_FLOATS)$(UCLIBC_SUSV3_LEGACY)),y) += \ >gcvt.c > CSRC-$(UCLIBC_SUSV3_LEGACY) += mktemp.c > > +CFLAGS-abort.c = -fasynchronous-unwind-tables > + > # multi source stdlib.c > CSRC-y += abs.c labs.c atoi.c atol.c strtol.c strtoul.c _stdlib_strto_l.c \ >qsort.c qsort_r.c bsearch.c \ > diff --git a/libpthread/nptl/sysdeps/unix/sysv/linux/Makefile.commonarch b/libpthread/nptl/sysdeps/unix/sysv/linux/Makefile.commonarch > index e28cec2..b32bc9b 100644 > --- a/libpthread/nptl/sysdeps/unix/sysv/linux/Makefile.commonarch > +++ b/libpthread/nptl/sysdeps/unix/sysv/linux/Makefile.commonarch > @@ -128,6 +128,8 @@ CFLAGS-timer_gettime.c = -I$(top_srcdir)librt -DIS_IN_librt > CFLAGS-timer_routines.c = -I$(top_srcdir)librt -DIS_IN_librt > CFLAGS-timer_settime.c = -I$(top_srcdir)librt -DIS_IN_librt > > +CFLAGS-raise.c = -fasynchronous-unwind-tables > + > CFLAGS-linux = -DNOT_IN_libc -DIS_IN_libpthread $(SSP_ALL_CFLAGS) > > CFLAGS-OMIT-libc_pthread_init.c = -DNOT_IN_libc -DIS_IN_libpthread > -- > 1.7.4.4 > > ___ > uClibc mailing list > uClibc@uclibc.org > http://lists.busybox.net/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: Is pthread_create() after a fork() fixable in the uClibc ?
On (22/12/11 02:25), Jean-Christian de Rivaz wrote: > As more I use the uClibc in systems, as more I face this old and > known problem. For reference it was known at least in 2007 > > http://lists.uclibc.org/pipermail/uclibc/2007-June/038936.html > > Obviously, even if it is arguable that the OpenGroup standard don't > define this case, more and more situations in the real world fall > into this. In one of the system we currently designed, we have 5 > completely unrelated applications that hang because of this. Some > can be fixed easily, but other cannot because of some complex > relation between libraries. > > Just an simple example: current Buildroot provides GVFS package that > can support a FUSE mount if the libfuse package is selected. The > gvfsd daemon start automatically the gvfs-fuse-daemon that use > pthread_create(). But gvfs-fuse-daemon, before calling > pthread_create(), call the libfuse that call uClibC daemon() that > internally call fork(). This end up to the pthread_create() after a > fork() situation that simply hang the process. Now, you can't blame > libfuse for using daemon() and you can't blame gvfs-fuse-daemon for > using libfuse and pthread_create(). In addition, gvfs-fuse-daemon > really have to call the libfuse library before pthread_create() > because this is into a callback from the library. > > Others common case where this hang is at the startup of the system, > when some multithreaded application are demonized. This can be > really annoying in case this is not open source code... > > It's difficult to scope this problem. I have see new programmer lost > days without having a clue about what can be false. I myself lost > the past two days adding debug in gvfs and libfuse before I started > to understand. > > The drama is that, even if the situation is not defined by the > OpenGroup, it actually work perfectly well with the glibc or the > eglibc, so that nobody care to fix it. More en more applications > uses pthread. And fork() without exec() just after it, like > daemon(), is not going to disappear by magic. > > So without starting a endless thread about the interpretation of the > standards, my motivation with this post is to collect as much > information as possible on the technical details that make the > others libc able to do pthread_create() after fork() and why uClib > can't. The hope is that an acceptable change in the uClibc can be > found to improve this. Do you see it when you use NPTL for pthread as well ? ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [ANNOUNCE] 0.9.33-rc1 released
On (30/12/11 20:39), Bernhard Reutner-Fischer wrote: > On Dec 30, 2011 8:32 PM, "Carmelo Amoroso" wrote: > > > > On 30 December 2011 12:55, Bernhard Reutner-Fischer > > wrote: > > > Hi, > > > > > > I have just tagged and tar'ed 0.9.33-rc1 > > > > > > Please test and report back, the final release is due to happen within > > > the next 2 weeks. > > > > > > Thanks in advance and enjoy! > > > > I hope to have a fix for FDPIC issues to include in rc2 early next year. I still need to debug further the issue I am seeing with X fonts ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
