Hello,
I'm trying to debug a RV-compiled program in GDB. Everything works fine accept the .data initialization.
Keil(ARM) is placing the .data PROGBITS initialization in the section with the base address of the real variables (RAM), see below for a LPC1768 example:
[ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] ROM1 PROGBITS 00000000 000034 000300 00 AX 0 0 4 [ 2] RESV PROGBITS 00001000 001034 0000bc 00 WA 0 0 4 [ 3] ROM2 PROGBITS 00002000 002034 02a970 00 AX 0 0 4 [ 4] SCRATCH PROGBITS 10000000 02c9a4 00002c 00 WA 0 0 4 [ 5] SCRATCH NOBITS 1000002c 02c9d0 006db4 00 WA 0 0 8
Section 4 is containing the init data for the .data section and this is in RAM and not in ROM.
The Region$$Table is pointing to 0x2a970 for the position of the init data, which is just right after all the usual ROM sections.
Result: The __scater_load fails at startup because the 0x2a970 region is filled with 0xFF (just empty). If the data is not compressed it goes to main with uninit .data segment, if the data was compressed it ends with a hard fault because of the decompression algorithm.
The question is, how does the fromelf tool knows that it has to put that section with base address 0x10000000 right behind the image at 0x02a970? In this example all the PROGBITS are placed in a row but this is not necessarily the case. It could also be in a other RAM segment.
I first thought that this was described in the SHT_NOTE but that isn't the case.
Any help appreciated.