Bug#767756: glibc: Consider providing a libc build compiled with -fno-omit-frame-pointer to help with profiling
Source: glibc Severity: wishlist Hi, When profiling with perf (and even oprofile) showing the call graph can often be invaluable. Unfortunately for anything that goes through libc that's not efficiently possible as glibc (on at least amd64) doesn't build with frame pointers enabled. It is possible to use dwarf unwinding with halfway modern kernel/perf combinations to get call graphs even in that case, but the overhead is about a magnitude higher and the profiles are much larger. As applications have to be built with -fno-omit-frame-pointers anyway to provide usable call stack it's usually not a problem if some library isn't. But as so many things that often are bottlenecks (syscalls, memcpy, string operations, locking, ...) goes through libc it'd be quite valuable to have a variant of libc built with frame pointers enabled. Thanks for considering, Andres -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.17.0-andres-09670-g0429fbc (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141102130847.28817.43507.report...@alap3.anarazel.de
Bug#767756: glibc: Consider providing a libc build compiled with -fno-omit-frame-pointer to help with profiling
Hi, On 2016-03-30 06:37:11 +, Alex Reece wrote: > I would love to bump this bug; I think it would be wonderful to have an > alternative version of libc with frame pointers. Yea, I'm hitting this more and more often. Especially with the new eBPF backed profiling tools like bcc, which, for the forseeable future, only support frame pointer based unwinding. Also fp based unwinding is a lot more efficient. > What would it take for such an alternative to exist (can the Debian > alternatives system work for libc)? I was thinking of adding a libc6-frame-pointers which would replace (and conflict with) libc6. But that's just because it was what I could think of. Maybe it'd be better to let those be co-installed by using a different triplet and allow to chose which to use via /etc/ld.so.conf/something? Not pretty either :( > If other people want this, I'm interested in investing some time into > helping with it. Same here. I'd primarily like some guidance about what approach is more likely to be accepted. Greetings, Andres Freund
Bug#930697: glibc: merge latest upstream 2.28 changes
Source: glibc Version: 2.28-10 Severity: normal Hi, There have been several fixes on the release/2.28/master branch. In particular https://sourceware.org/bugzilla/show_bug.cgi?id=24476 at the moment causes a lot of false positives when using valgrind on applications that don't use dlopen() (postgres in my case). But a few of the other changes since the last upstream merge also seem worth pulling in. Regards, Andres Freund
