addr2line stumbles upon the gap in the elf line information
addr2line produces different address descriptions when addresses ran separately, and in a batch. Here is an example. I supply two addresses to the standard input of this command: addr2line -f -C -e my.elf 0003a39b 0004e4f4 Relevant sections of this elf dump: pc[row,col] NS BB ET PE EB IS= DI= uri: filepath 0x00039e10 [ 111, 0] NS uri: src1 0x00039e27 [ 112,13] NS PE 0x00039e43 [ 111,46] NS ...skipped... 0x0003a386 [ 102, 5] NS 0x0003a388 [ 109, 5] NS// here is the first address 0x0003a39e [ 102, 5] NS 0x0003a3a5 [ 99,44] NS 0x0003a3b4 [ 109, 5] NS ...skipped... pc[row,col] NS BB ET PE EB IS= DI= uri: filepath 0x0004e3d0 [ 15, 0] NS uri: src2 0x0004e3e5 [ 16, 5] NS PE 0x0004e479 [ 18, 0] NS 0x0004e482 [ 16, 5] NS 0x0004e4a0 [ 177, 0] NS 0x0004e4a4 [ 178, 8] NS PE ...here is a gap in line info ... // second address is in this gap 0x0004e51e [ 178, 5] NS 0x0004e5b4 [ 179, 0] NS When both addresses are supplied in a batch, the output is wrong: func1() src1:109 func2() src1:99 When addresses are supplied one by one, the output is different: func1() src1:109 func2() src2:178 Technically, the second address doesn't have the line information. So both outputs are wrong. But for some reason, 'echo 0004e4f4 | addr2line -f -C -e my.elf' extrapolates (?) and comes up with the better answer. Not sure if this is supposed to be this way. This is certainly a bug that the batch command produces the wrong output. And I am not sure if standalone command is supposed to extrapolate or not. Probably not. binutils-2.24 Yuri ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/16698] BFD (GNU Binutils) 2.24 assertion fail elf32-arm.c:12387
https://sourceware.org/bugzilla/show_bug.cgi?id=16698 --- Comment #21 from Nick Clifton nickc at redhat dot com --- I am sorry but this bug is just not reproducible with the FSF mainline binutils sources. :-( I can only conclude that the bug must be something to do with whatever patches CodeSourcery have applied to their toolchain. Nick -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/16698] BFD (GNU Binutils) 2.24 assertion fail elf32-arm.c:12387
https://sourceware.org/bugzilla/show_bug.cgi?id=16698 --- Comment #22 from maillist-gdb at barfooze dot de --- are you sure you're not using a hardfloat toolchain ? those seem to be immune to the bug. anything else i tested is affected. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/17288] sh64 incremental link does not set flags in ELF header
https://sourceware.org/bugzilla/show_bug.cgi?id=17288 --- Comment #3 from David Howells dhowells at redhat dot com --- Using --whole-archive seems to work. + sh64-linux-gnu-ar rcsD wibble.o hello.o + sh64-linux-gnu-ld -EL -mshlelf64 --whole-archive -r -o foo.o wibble.o + sh64-linux-gnu-readelf -h foo.o + grep Flags Flags: 0xa, sh5 + sh64-linux-gnu-ld -EL -mshlelf64 -r -o bar.o foo.o + sh64-linux-gnu-readelf -h bar.o + grep Flags Flags: 0xa, sh5 -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
