Hi all,
I'm trying to get gbd backtraces to give function names without having a package's debuginfo installed. Would elfutils take a patch allowing strip to take an option for keeping the minimal amount of information needed to do this?
I'm still trying to figure out how to do this exactly but right now I think I would be keeping SHT_SYMTAB and SHT_DYNSYM function symbols but I haven't looked at this code before and I'm still trying to figure out how it all comes together. Any advice would be appreciated if you'd be okay with this functionality in elfutils.
Thanks, William
On 05/07/2012 01:51 PM, Douglas, William wrote:
Hi all,
I'm trying to get gbd backtraces to give function names without having a package's debuginfo installed. Would elfutils take a patch allowing strip to take an option for keeping the minimal amount of information needed to do this?
I'm still trying to figure out how to do this exactly but right now I think I would be keeping SHT_SYMTAB and SHT_DYNSYM function symbols but I haven't looked at this code before and I'm still trying to figure out how it all comes together. Any advice would be appreciated if you'd be okay with this functionality in elfutils.
William,
I can't answer for the elfutils library itself, but you might want to look at/help out with a proposed new F18 feature called 'MiniDebugInfo', which sounds similar to what you want to do.
http://news.gmane.org/gmane.linux.redhat.fedora.devel https://fedoraproject.org/wiki/Features/MiniDebugInfo
On Mon, May 7, 2012 at 12:19 PM, David Smith dsmith@redhat.com wrote:
William,
I can't answer for the elfutils library itself, but you might want to look at/help out with a proposed new F18 feature called 'MiniDebugInfo', which sounds similar to what you want to do.
http://news.gmane.org/gmane.linux.redhat.fedora.devel https://fedoraproject.org/wiki/Features/MiniDebugInfo
Ah that is an interesting, thanks for the link!
On Mon, May 7, 2012 at 12:35 PM, Roland McGrath roland@hack.frob.com wrote:
It sounds like you want strip -g, which has existed for many years.
That's what I'm seeing right now when I try it. That is very confusing as on a different system last week I had strip -g -f when you don't have access to the debuginfo file it outputs showing ?? for the function names but if I readelf the binaries on this system I clearly see functions in the symtab table. I'll have to get back on that system tomorrow and see what I did/missed, thanks.
On Mon, May 7, 2012 at 2:04 PM, Douglas, William william.douglas@intel.com wrote:
On Mon, May 7, 2012 at 12:35 PM, Roland McGrath roland@hack.frob.com wrote:
It sounds like you want strip -g, which has existed for many years.
That's what I'm seeing right now when I try it. That is very confusing as on a different system last week I had strip -g -f when you don't have access to the debuginfo file it outputs showing ?? for the function names but if I readelf the binaries on this system I clearly see functions in the symtab table. I'll have to get back on that system tomorrow and see what I did/missed, thanks.
Coming back to this finally. The problem I was running into was that the libraries were being stripped on the machine I had initially tested this on causing the the problem I was running into where debuginfo missing caused outputs of ?? in the backtrace.
Minimal example with glib getting the strip -g treatment is the following crash.c:
#include <stdlib.h> #include <stdio.h>
#include <glib.h>
int main(void) { char *c ;
c = g_malloc(5); g_free(c); g_free(c); }
$ gcc -g $(pkg-config --cflags glib-2.0 --libs glib-2.0) crash.c -o crash $ gdb crash (gdb) run (gdb) bt #0 0x00007ffff77279e5 in raise () from /lib64/libc.so.6 #1 0x00007ffff7729198 in abort () from /lib64/libc.so.6 #2 0x0000000000000020 in ?? () #3 0x0000000000000000 in ?? ()
Is there something I'm doing wrong or is this not expected to work?
$ gdb crash (gdb) run (gdb) bt #0 0x00007ffff77279e5 in raise () from /lib64/libc.so.6 #1 0x00007ffff7729198 in abort () from /lib64/libc.so.6 #2 0x0000000000000020 in ?? () #3 0x0000000000000000 in ?? ()
Is there something I'm doing wrong or is this not expected to work?
This backtrace shows PC values that are not plausible. That indicates that something went wrong with unwinding from the outermost libc frame there. Whatever the story on that, the caller code having had 'eu-strip -g' run on it has nothing to do with it. If you get to the point of a backtrace with all the PC values correct but you are missing useful symbolic information for those PCs, then we can help you look into that.
elfutils-devel@lists.fedorahosted.org