Compiler-generated implicit symbols and --gc-sections
Mike
none at none.com
Fri Jan 3 10:14:56 PST 2014
I ran into a problem recently that resulted in a segmentation
fault in my program whenever I called a member function of one of
my classes. Sometimes it occurred and sometimes it didn't
depending on the order of certain things in my code.
I eventually tracked it down to the fact that I was compiling
with -ffunction-sections and -fdata-sections and linking with
--gc-sections and symbols like...
.data._D38TypeInfo_E14TypeInfo_Class10ClassFlags6__initZ
.data._D40TypeInfo_E15TypeInfo_Struct11StructFlags6__initZ
... were being discarded. I'm assuming this is the mangled .init
values of these types, yes?
My linker script contained...
.data : AT (__data_rom_begin)
{
. = ALIGN(4);
__data_ram_begin = .;
. = ALIGN(4);
*(.data)
*(.data*)
. = ALIGN(4);
__data_ram_end = .;
} >SRAM
... so I was forced to conclude that the reason they were being
discarded was because it couldn't find any code that was reaching
these symbols.
After adding...
KEEP(*(.data.*init*))
... to my linker script, the problem was resolved.
I'm guessing these are generated implicitly by the GDC compiler,
but it does appear that my code never reaches these symbols, so
discarding them should be OK. However, it seems discarding them
causes dislocation in memory.
I'm still a novice with GCC-based toolchains, so forgive the
ignorance of this question, but is this to be expected, or is
this an indication of a problem with the compiler?
Mike
Compiler:
Latest GDC 4.8 compiled for arm-none-eabi (ARM Cortex-M)
More information about the D.gnu
mailing list