My problem with the LD linker

My problem with the LD linker

[Marian Kechlibar]

So, why I originally asked about "gold" linker... I am experiencing
trouble with linking a huge project and I hoped that "gold" may get
me rid of this problem. But I reckon I might just ask about my original
problem, perhaps someone is going to help me.

The context: I have five projects for Symbian OS:

Killer
Cleaner
Server
Tester
Expert

I can compile and link them either using:

* ARMCC/ARMLINK 2.2
or
* GCC(E) 4.6.3 and Binutils 2.21 or 2.27.

The first option (ARM) produces usable binaries, but the compiler is
really old and does not support things such as framepointer.

The second option (GCC/Binutils) works for the first four projects, but
the link phase (using ld) fails for the fifth project, saying:

========================================================================
arm-none-symbianelf-ld:
\S60\devices\S60_3rd_FP2_SDK_v1.1\epoc32\release\ARMV5\urel\EEXE.LIB(uc_exe_.o)(.text+0x2):
unresolvable R_ARM_THM_CALL relocation against symbol
`_ZN4User9InvariantEv@@euser{000a0000}[100039e5].dll'

arm-none-symbianelf-ld: final link failed: Nonrepresentable section on
output
========================================================================

Now, this is not caused by omission of a library.
The symbol User::Invariant is contained in the system libraries
and is actually used within the project "Cleaner" as well. So the
complaint is strange.

I have a suspicion that the problem is in *size* of the resulting
binary. The "Expert" project is rather big, several times bigger
than the "Cleaner" project. But I do not understand ELF well enough
to remedy the problem.

Is it possible that some section of the resulting ELF file overflows?

Any ideas would be appreciated.

Re: My problem with the LD linker

[Nick Clifton]

Hi Marian,

> I can compile and link them either using:
> 
> * ARMCC/ARMLINK 2.2
> or
> * GCC(E) 4.6.3 and Binutils 2.21 or 2.27.

> The second option (GCC/Binutils) works for the first four projects, but
> the link phase (using ld) fails for the fifth project, saying:
> 
> ========================================================================
> arm-none-symbianelf-ld:
> \S60\devices\S60_3rd_FP2_SDK_v1.1\epoc32\release\ARMV5\urel\EEXE.LIB(uc_exe_.o)(.text+0x2):
> unresolvable R_ARM_THM_CALL relocation against symbol
> `_ZN4User9InvariantEv@@euser{000a0000}[100039e5].dll'


> I have a suspicion that the problem is in *size* of the resulting
> binary. The "Expert" project is rather big, several times bigger
> than the "Cleaner" project. But I do not understand ELF well enough
> to remedy the problem.

> Is it possible that some section of the resulting ELF file overflows?

Yes.  It may well be that the executable is so big that the distance from where
the Invariant function is being called and where it is being defined will not
fit into the Thumb function call instruction.

Several ideas come to mind:

  * Compile for ARM rather than THUMB - the ARM supports a larger address space.

  * Compile with GCC but link with ARMLINK.  (You did say that using ARMCC/ARMLINK works).

  * Compile with -ffunction-sections and -fdata-sections enabled and then link with -gc-sections enabled.
    This might help to reduce the code size by eliminating unused code/data.

  * Change the order of the object files on the linker command line so that uc_exe.o
    object is located closer to the system library that defines it.

  * Compile with -mlong-calls enabled so that function calls to far away destinations should work.

Cheers
  Nick

Re: My problem with the LD linker

[Marian Kechlibar]

Hi Nick,

thank you for your suggestions.

ARMLINK 2.2 will not work with objects compiled by GCC 4.6.3, complains
about invalid object file.

I was nevertheless lucky anyway, though it is embarrasing to admit. My
LD of 2.27 version works! The trouble was that when I substituted LD
2.21 for the newer 2.27, I did not notice that another copy of the
older, faulty 2.21 lingered somewhere on the disk, and unfortunately on
the system path.

As soon as I discovered it and got rid of it, things got better. I can
link my EXE now. It is only about 9 MB big, not a big deal.

Thank you for your help.

Marian

Dne 22.2.2017 v 13:07 Nick Clifton napsal(a):
> Hi Marian,
> 
>> I can compile and link them either using:
>>
>> * ARMCC/ARMLINK 2.2
>> or
>> * GCC(E) 4.6.3 and Binutils 2.21 or 2.27.
> 
>> The second option (GCC/Binutils) works for the first four projects, but
>> the link phase (using ld) fails for the fifth project, saying:
>>
>> ========================================================================
>> arm-none-symbianelf-ld:
>> \S60\devices\S60_3rd_FP2_SDK_v1.1\epoc32\release\ARMV5\urel\EEXE.LIB(uc_exe_.o)(.text+0x2):
>> unresolvable R_ARM_THM_CALL relocation against symbol
>> `_ZN4User9InvariantEv@@euser{000a0000}[100039e5].dll'
> 
> 
>> I have a suspicion that the problem is in *size* of the resulting
>> binary. The "Expert" project is rather big, several times bigger
>> than the "Cleaner" project. But I do not understand ELF well enough
>> to remedy the problem.
> 
>> Is it possible that some section of the resulting ELF file overflows?
> 
> Yes.  It may well be that the executable is so big that the distance from where
> the Invariant function is being called and where it is being defined will not
> fit into the Thumb function call instruction.
> 
> Several ideas come to mind:
> 
>   * Compile for ARM rather than THUMB - the ARM supports a larger address space.
> 
>   * Compile with GCC but link with ARMLINK.  (You did say that using ARMCC/ARMLINK works).
> 
>   * Compile with -ffunction-sections and -fdata-sections enabled and then link with -gc-sections enabled.
>     This might help to reduce the code size by eliminating unused code/data.
> 
>   * Change the order of the object files on the linker command line so that uc_exe.o
>     object is located closer to the system library that defines it.
> 
>   * Compile with -mlong-calls enabled so that function calls to far away destinations should work.
> 
> Cheers
>   Nick
> 
>