Compiler-generated implicit symbols and --gc-sections

Joakim joakim at airpost.net
Thu Jan 9 08:44:46 PST 2014


On Thursday, 9 January 2014 at 10:15:46 UTC, Mike wrote:
> On Thursday, 9 January 2014 at 07:51:48 UTC, Mike wrote:
>> On Tuesday, 7 January 2014 at 11:04:45 UTC, Joakim wrote:
>>> I ran into this recently when compiling for Android/x86, as 
>>> the Android NDK linker calls --gc-sections by default.  I was 
>>> able to reproduce the segfault with dmd compiling a linux/x86 
>>> executable with the --gc-sections flag added to the linker 
>>> command, when compiling sieve.d from the samples.  I think 
>>> sieve.d was working fine when I removed the recent patches 
>>> for shared library support on linux, in sections_linux.d, so 
>>> this incompatibility might be related to the shared library 
>>> work.  I'm not sure if you're even using that work though, so 
>>> maybe that's just one of the ways that gc-sections trips up.
>>
>> Interesting!  I'd like to take the current 4.8 backport and 
>> compile it without the shared library stuff to test this out.  
>> But I don't know how.  Would you mind giving me a quick 
>> explanation on how to remove these patches using git?  I'm 
>> really quite new to some of these tools.
>
> Nevermind that last post. I thought you were talking about code 
> in GDC, not the runtime.  My runtime is only about 400 lines 
> total, and I'm not anywhere near sections.d.

Yeah, that's in druntime, which is what I'm porting to 
Android/x86.  Interestingly, the segfault would go away if I 
removed --gc-sections, so that alone seemed to be causing it, on 
both linux/x86 and Android/x86.


More information about the D.gnu mailing list