eu-strip segfaults on archives
by Mike Frysinger
seems like eu-strip segfaults on any archive given it. a simple example, run
strip on the libar.a in the src/ subdir. current master with glibc-2.14 + gcc-4.6:
$ LD_LIBRARY_PATH=../libelf/ gdb --args ./strip libar.a
Reading symbols from /usr/local/src/elfutils/src/strip...done.
(gdb) r
Starting program: /usr/local/src/elfutils/src/strip libar.a
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7bcc7b3 in elf_end (elf=0x60f520) at elf_end.c:119
119 while (child->next != elf)
(gdb) bt
#0 0x00007ffff7bcc7b3 in elf_end (elf=0x60f520) at elf_end.c:119
#1 0x0000000000403273 in handle_elf (fd=0x7, elf=<optimized out>, prefix=<optimized out>, mode=0x0, tvp=0x0) at strip.c:2036
#2 0x00000000004067d2 in handle_ar (fd=0x7, elf=0x60e050, prefix=<optimized out>, fname=0x7fffffffd68c "libar.a", tvp=0x0) at strip.c:2111
#3 0x0000000000406b7d in process_file (fname=0x7fffffffd68c "libar.a") at strip.c:380
#4 0x000000000040233b in main (argc=0x2, argv=0x7fffffffd308) at strip.c:208
-mike
12 years
elflint and gold
by Kurt Roeckx
Hi,
It seems that gold causes elflint to generate errors.
Ian Lance Taylor wrote:
> Thanks for the test case. The elflint program is getting confused when it
> tries to find the .dynamic section. The PT_DYNAMIC segment is at address
> 0x32000. It happens that the .tbss section is at sddress 0x32000. Since the
> .tbss section is SHT_NOBITS, it does not take up any address space. The
> .dynamic section then follows it, also at address 0x32000. In the readelf -S
> output:
>
> [18] .tbss NOBITS 0000000000032000 00032000
> 0000000000000008 0000000000000000 WAT 0 0 4
> [19] .dynamic DYNAMIC 0000000000032000 00032000
> 0000000000000240 0000000000000010 WA 3 0 8
>
> This is confusing elflint. It is using gelf_offscn to return the section at
> offset 0x32000. That winds up being the .tbss section, not the .dynamic
> section. Based on that it decides that there are no DT_NEEDED entries, and
> issues the .gnu.version_r warnings.
>
> I don't see any gold problem here.
Please see http://sourceware.org/bugzilla/show_bug.cgi?id=12945
Kurt
12 years
Speedup dwfl_module_addrsym
by Mark Wielaard
Hi,
dwfl_module_addrsym is a bit slow because it wants to return global
symbols in preference to local symbols, but first looks at all the local
symbols. To speed this up I wrote the following patches, which
introduces dwfl_module_symtab_global to get the first index of the
global symbols in the symtab. And the uses this in dwfl_module_addrsym
to search through the global symbols first, and only if no symbol was
found, go through the local symbols afterwards.
This gives a nice speedup on readelf -w libstdc++.so.debug for example,
from 35 seconds to 25 seconds, on my machine. The output is exactly the
same.
Comments?
Thanks,
Mark
12 years, 1 month