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