Understanding GCC generated map files

1

I'm trying to write a script that parses .map files generated by GCC and help me figure out what the footprints of various libraries are in memory. (Github repository of what I have so far)

I'm trying to understand what the following means / how it should be read :

.debug_line     0x00000000     0x67b1
 *(.debug_line .debug_line.* .debug_line_end)
 .debug_line    0x00000000      0x105 /opt/ti/gcc/bin/../lib/gcc/msp430-elf/4.9.1/../../../../msp430-elf/lib/crt0.o
 .debug_line    0x00000105      0x4b5 CMakeFiles/firmware-msp430f5529.elf.dir/main.c.obj
 .debug_line.text.bc_printf.constprop.1
                0x000005ba       0x23 CMakeFiles/firmware-msp430f5529.elf.dir/main.c.obj
 .debug_line.text.deferred_exec
                0x000005dd       0x60 CMakeFiles/firmware-msp430f5529.elf.dir/main.c.obj
 .debug_line.text.startup.main
                0x0000063d       0xfc CMakeFiles/firmware-msp430f5529.elf.dir/main.c.obj
 .debug_line_end
                0x00000739        0x0 CMakeFiles/firmware-msp430f5529.elf.dir/main.c.obj

I've been assuming the first line, which is not indented, is some sort of section heading and that the address (0x0000000) somehow relates to where the contents of the section should be written. 0x00000000 somehow results in the contents being discarded.

The indented lines (those which start with .debug_line) also have an address. These addresses, when the symbol is going to be written to the binary, are absolute.

.text           0x000048d8     0x3312
                0x000048d8                . = ALIGN (0x2)
 *(.lower.text.* .lower.text)
                0x000048d8                . = ALIGN (0x2)
 *(.text .stub .text.* .gnu.linkonce.t.* .text:*)
 .text          0x000048d8       0xa4 /opt/ti/gcc/bin/../lib/gcc/msp430-elf/4.9.1/crtbegin.o
 .text.bc_printf.constprop.1
                0x0000497c       0x1a CMakeFiles/firmware-msp430f5529.elf.dir/main.c.obj

How does the address in the section heading, or whatever the first line should be called, translate to the address in the actual symbols and so forth? i.e., How would 0x00000000 result in the symbols being discarded (even though the addresses they contain may indeed be valid writeable locations otherwise)

What does the indented line beginning with a *, i.e. *(.debug_line .debug_line.* .debug_line_end) mean? I'm fairly certain this line is critical to defining the treatment of the second last line in the first snippet, since .debug_line_end isn't defined all by itself in a way similar to how .debug_line is in the first line of the snippet. I can't seem to find any references to the structure of the file, though.

With those answers, I'd like to be able to understand how .eh_frame in the following snippet is resolved. I can post the full map file if it's necessary, but I suspect all the information needed is somehow encoded within the snippet, and at that within the top and bottom few lines only.

.rodata         0x00004400      0x464
                0x00004400                . = ALIGN (0x2)
 *(.plt)
                0x00004400                . = ALIGN (0x2)
 *(.lower.rodata.* .lower.rodata)
                0x00004400                . = ALIGN (0x2)
 *(.rodata .rodata.* .gnu.linkonce.r.* .const .const:*)
 .rodata        0x00004400       0x11 CMakeFiles/firmware-msp430f5529.elf.dir/main.c.obj
 *fill*         0x00004411        0x1
 .rodata.tUsbRequestList
                0x00004412      0x15c ../peripherals/USB_config/libusb-config-msp430f5529.a(descriptors.c.obj)
                0x00004412                tUsbRequestList
 .rodata.stUsbHandle
                0x0000456e       0x40 ../peripherals/USB_config/libusb-config-msp430f5529.a(descriptors.c.obj)
                0x0000456e                stUsbHandle
 .rodata.report_desc_HID0
                0x000045ae       0x24 ../peripherals/USB_config/libusb-config-msp430f5529.a(descriptors.c.obj)
                0x000045ae                report_desc_HID0
 .rodata.abromStringDescriptor
                0x000045d2      0x146 ../peripherals/USB_config/libusb-config-msp430f5529.a(descriptors.c.obj)
                0x000045d2                abromStringDescriptor
 .rodata.abromConfigurationDescriptorGroup
                0x00004718       0xef ../peripherals/USB_config/libusb-config-msp430f5529.a(descriptors.c.obj)
                0x00004718                abromConfigurationDescriptorGroup
 .rodata.abromDeviceDescriptor
                0x00004807       0x12 ../peripherals/USB_config/libusb-config-msp430f5529.a(descriptors.c.obj)
                0x00004807                abromDeviceDescriptor
 *fill*         0x00004819        0x1
 .rodata.report_desc_size
                0x0000481a        0x2 ../peripherals/USB_config/libusb-config-msp430f5529.a(descriptors.c.obj)
                0x0000481a                report_desc_size
 .rodata        0x0000481c       0x11 ../subsystem/libcontrol-iface-msp430f5529.a(control_iface.c.obj)
 *fill*         0x0000482d        0x1
 .rodata.GPIO_PORT_TO_BASE
                0x0000482e       0x1c ../peripherals/driverlib/MSP430F5xx_6xx/libdriverlib-msp430f5529.a(gpio.c.obj)
 .rodata        0x0000484a        0x7 ../lib/libprintf-msp430f5529.a(printf.c.obj)
 *(.rodata1)
 *(.eh_frame_hdr)
 *(.eh_frame)
 *fill*         0x00004851        0x3
 .eh_frame      0x00004854        0x0 /opt/ti/gcc/bin/../lib/gcc/msp430-elf/4.9.1/crtbegin.o
c
gcc
linker
msp430
asked on Stack Overflow Apr 1, 2015 by Chintalagiri Shashank • edited Apr 1, 2015 by Chintalagiri Shashank

0 Answers

Nobody has answered this question yet.


User contributions licensed under CC BY-SA 3.0