[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