[Bug remote/23209] New: GDB skips padding when loading ELF to target

["krokoziabla at gmail dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=23209

            Bug ID: 23209
           Summary: GDB skips padding when loading ELF to target
           Product: gdb
           Version: 8.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: remote
          Assignee: unassigned at sourceware dot org
          Reporter: krokoziabla at gmail dot com
  Target Milestone: ---

I have a STM32F4 Discovery board, OpenOCD debug server and
armv7m-unknown-eabi-gdb and want my board to run a bare-metal ELF which I've
built. I start gdb, give it target remote :3333, load, monitor reset halt
commands and then try to step through the code but nothing works. After some
investigation I've found that the code was uploaded at a wrong address.

readelf -S gives:

[ 1] vectors           PROGBITS        00000000 000114 000040 00   A  0   0  1
[ 2] .interp           PROGBITS        00000040 000154 000011 00   A  0   0  1
[ 3] .dynsym           DYNSYM          00000054 000168 000030 10   A  4   3  4
[ 4] .dynstr           STRTAB          00000084 000198 000001 00   A  0   0  1
[ 5] .hash             HASH            00000088 00019c 000018 04   A  3   0  4
[ 6] .text             PROGBITS        000000a0 0001b4 000134 00 WAX  0   0  4

And you can see that the linker put two 3-byte paddings: the first one between
.interp and .dynsym and the second one between .dynstr and .hash sections.

But when gdb loads the image onto the board it seems to ignore these gaps and
put the sections one right after the other (nevermind 0x2xxxxxxx addresses, the
CPU is configured to map them to 0x0xxxxxxx region):

(gdb) load
Loading section vectors, size 0x40 lma 0x20000000
Loading section .interp, size 0x11 lma 0x20000040
Loading section .dynsym, size 0x30 lma 0x20000051
Loading section .dynstr, size 0x1 lma 0x20000081
Loading section .hash, size 0x18 lma 0x20000082
Loading section .text, size 0x134 lma 0x2000009a

As the result the code finds itself 6 bytes before the address GDB expects it
to be at and thus all the debugging info applies to memory incorrectly. I
literally get crazy results because the next instruction I'm going to execute
(that is the one which GDB points at) in fact is some other one (to be exact,
it's the current instruction + 3 halfwords).

So, what can be wrong? Do I use GDB incorrectly? Or is it ELF that was build
wrongly? Maybe OpenOCD is the culprit? Or something else?

-- 
You are receiving this mail because:
You are on the CC list for the bug.