https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89207

            Bug ID: 89207
           Summary: Symbols missing in map file with LTO
           Product: gcc
           Version: 8.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ilg at livius dot net
                CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 45607
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45607&action=edit
The elf, the map and the listing.

After finally managing to compile some embedded projects with arm-none-eabi-gcc
and '-flto', I noticed that the map file (created with something like
'-Wl,-Map,"f4b-lto-map.map"') does not include all symbols, although the
listing file created with objcopy does, so the symbols are present in the elf
file.

I attached an archive with the elf, the map and the listing.

There are multiple symbols missing, but I noticed the problem while searching
the map for the 'Reset_Handler', located, according to the the listing, at
0x080003ac:


080003ac <Reset_Handler>:
Reset_Handler():
/Users/ilg/Desktop/eclipse-workspace-2018-12/f4b-lto-map/Debug/../system/src/cortexm/exception_handlers.c:53
{
 80003ac:       b508            push    {r3, lr}
/Users/ilg/Desktop/eclipse-workspace-2018-12/f4b-lto-map/Debug/../system/src/cortexm/exception_handlers.c:54
  _start ();
 80003ae:       f7ff ff79       bl      80002a4 <_start>


Then I noticed that the entire .after_vectors has only 4 symbols:

 *(.after_vectors .after_vectors.*)
 .after_vectors
                0x0000000008000188      0x238
/var/folders/n7/kxqjc5zs4qs0nb44v1l2r2j00000gn/T//ccTOZd7j.ltrans0.ltrans.o
                0x00000000080001dc                UsageFault_Handler_C
                0x0000000008000210                BusFault_Handler_C
                0x0000000008000244                HardFault_Handler_C
                0x00000000080002a4                _start

.inits          0x00000000080003c0       0x2c
                0x00000000080003c0                __data_regions_array_start =
.


while in reality the listing for this memory range includes many more.

For example, the same program compiled without -flto, shows for the
.after_vectors section the following:


 .after_vectors
                0x0000000008000188      0x130 ./system/src/newlib/_startup.o
                0x0000000008000188                _start
 .after_vectors
                0x00000000080002b8      0x12c
./system/src/cortexm/exception_handlers.o
                0x00000000080002b8                Reset_Handler
                0x00000000080002be                NMI_Handler
                0x00000000080002c2                HardFault_Handler
                0x00000000080002d6                HardFault_Handler_C
                0x0000000008000334                MemManage_Handler
                0x0000000008000338                BusFault_Handler
                0x000000000800034c                BusFault_Handler_C
                0x0000000008000380                UsageFault_Handler
                0x0000000008000394                UsageFault_Handler_C
                0x00000000080003c8                SVC_Handler
                0x00000000080003cc                DebugMon_Handler
                0x00000000080003d0                PendSV_Handler
 .after_vectors
                0x00000000080003e4        0x4
./system/src/cmsis/vectors_stm32f407xx.o
                0x00000000080003e4                DMA1_Stream3_IRQHandler
(... many more ...)
                0x00000000080003e4                RTC_Alarm_IRQHandler

.inits          0x00000000080003e8       0x2c
                0x00000000080003e8                __data_regions_array_start =
.


I am aware that with LTO the code is restructured, and some functions may be
inlined, thus disapearing from the symbol table, but in this case the symbols
seem to remain in the symbol table, the problem being that the map generator
ommits them in the output file.

I'm using the Arm Embedded GCC 8.2.1 toolchain on a macOS.

Reply via email to