It seems GNU toolchain does not like me, but no worries, it's mutual and I'm not alone
So, did you know that gdb sometimes fails to load symbols from an elf file correctly? What a shame...
I've googled a lot, but all I could find is unanswered questions, a few links:
http://stackoverflow.com/questions/30128561/gdb-sets-breakpoint-on-incorrect-addresshttp://stackoverflow.com/questions/25333585/gdb-set-a-breakpoint-at-a-wrong-address-for-a-template-functionhttps://www.sourceware.org/ml/gdb/2004-07/msg00107.htmlHere's an example to demonstrate:
Code:
$ objdump -d ps2.so
0000000000000169 <irq1>:
169: 66 b9 00 02 mov $0x200,%cx
....
As you can see, the symbol table is correct in the ELF, irq1 function is at 0x169. Now in gdb:
Code:
(gdb) hbreak irq1
Hardware assisted breakpoint 1 at 0x205081
(gdb) disass *0x205169
No function contains specified address.
(gdb)
Right in the middle of the ELF header... And gdb refuses to disassemble the correct address. Nice, good job GNU developers! (Why can't I disassemble any arbitrary address, btw?)
Anyway if any of you face the same problem, the solution is simple, use 'add-symbol-file' instead of 'symbol-file' and add 0xe8 (the size of the ELF header) to the relocation address:
Code:
(gdb) add-symbol-file bin/root/lib/sys/input/ps2.so 0x2050e8
add symbol table from file "bin/root/lib/sys/input/ps2.so" at
.text_addr = 0x2050e8
(y or n) y
Reading symbols from bin/root/lib/sys/input/ps2.so...(no debugging symbols found)...done.
(gdb) hbreak irq1
Hardware assisted breakpoint 1 at 0x205169
(gdb) disass irq1
Dump of assembler code for function irq1:
...
Hope this saves someone a big headache some day.
Happy debugging!