gm2
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gm2] A burst of internal compiler issues from gm2-6.4.0, when linki


From: Gaius Mulley
Subject: Re: [Gm2] A burst of internal compiler issues from gm2-6.4.0, when linking a stand-alone application
Date: Wed, 06 Dec 2017 17:01:59 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

John Dubery <address@hidden> writes:

> On 22/11/17 17:00, address@hidden wrote:
>> ------------------------------
>> Message: 2
>> Date: Wed, 22 Nov 2017 10:19:07 +0000
>> From: Gaius Mulley <address@hidden>
>> To: John Dubery <address@hidden>
>> Cc: "address@hidden" <address@hidden>
>> Subject: Re: [Gm2] A burst of internal compiler issues from gm2-6.4.0
>>      when linking a stand-alone application
>> Message-ID: <address@hidden>
>> Content-Type: text/plain
>>
>> John Dubery <address@hidden> writes:
>>
>>
>> Hi John,
>>
>>>      gm2 -static -nostdlib -nostartfiles -fno-exceptions -fno-pth -
>>>      fm2-whole-program -flibs=min -fonlylink -TSimple.ld ScreenTest.o
>>>      ScreenTest-start.o -o ScreenTest.elf
>> gm2 needs the source file of the top program module as well on the
>> command line.  It uses this to generate the scaffold of module calls for
>> all dependant modules (the order can be overwritten by you if
>> necessary).
>>
>> It might be worth trying:
>>
>> $ gm2 -static -nostdlib -nostartfiles -fno-exceptions -fno-pth -
>>    fm2-whole-program -flibs=min -fonlylink -TSimple.ld ScreenTest.o
>>    ScreenTest-start.o -o ScreenTest.elf -v  ScreenTest.mod
>>
>> regards,
>> Gaius
>>
> Gaius,
> Thanks.
> Adding the source file didn't make any difference to the list of 
> errors.  I've looked at the issues more and it seems to me that in both 
> cases the compiler is not putting in code that it has determined the 
> program needs.  It's relying on the libraries to have the missing pieces.
>
> I link with -nostdlib so there are no libraries to be linked in. When I 
> remove this option (and the simple load file) there is no error 
> reported.  That sounds great but, unfortunately, the binary size jumps 
> from about 5Kb to 500Kb!
>
> 1 MOD & DIV
> I'm fairly sure that the missing function - __aeabi_ldivmod - is needed 
> to get the correct answer for the complicated +ve/-ve cases. On this 
> occasion I don't need that extra evaluation but even when I change to 
> all CARDINALs (I've even tried CARDINAL(10) as a divisor) an extra 
> function is still needed: __uidiv.
>
> I've solved the problem on this occasion by using repeated subtraction.  
> However, I guess I feel that the compiler should fetch this code as soon 
> as it is seen to be needed, rather than rely on a library to be linked.  
> Alternatively, could there be a very small library that provides just 
> these 2 functions?
>
> 2. unwind-arm-common.inc - can't find abort, etc.
> These cases seem to be caused by the inclusion of code for unwinding the 
> stack but not the functions that this extra code calls - __exidx_end, 
> __exidx_start, memcpy, abort.  I don't need this stack unwinding 
> facility at the moment, as far as I know.  One of my compiler options is 
> "-fno-exceptions" and I have also tried "-fno-unwind-tables" but that 
> made no difference.  What can I do to prevent the inclusion of any 
> unwinding code?
>
> Is it reasonable to say that code should be generated only for language 
> features used, e.g. MOD & DIV, or listed in IMPORT statements?
>
> Regards,
> John

Hi John,

I'm not sure of the solution yet - but will investigate this.  It is
certainly of interest and gm2 should be able to link and target tiny
memory platforms.  I suspect it is simply missing a library - but will
attempt to replicate this on an arm platform,

regards,
Gaius



reply via email to

[Prev in Thread] Current Thread [Next in Thread]