LD scripts - using expressions correctly

LD scripts - using expressions correctly

[David Paterson]

Hi folks,

I'm trying to use expressions to calculate addresses in a script but
keep getting some odd results.

My plan is, rather than having different scripts for different build
configurations, to allow users to select link options via defined
symbols.

For example, in some systems, code may execute faster from RAM, so it
might be required to copy the text section to the start of RAM.
However, the trap table might also be copied to RAM if it has to be
modified by the user's code (this is on a SPARC system BTW) so a gap
needs to be left for the trap table.

My linker script contains the following lines (I think the symbols are
self-explanatory) :-

  _textLMA = .;
  _textoffset = _traps_ram ? (_exec_rom ? 0 : 4K) : 0;
  _textVMA = (_exec_rom > 0) ? _textLMA : _ram_start;
  _textVMA += _textoffset;
  . = _textVMA;
  _wherestext1 = .;

  .text . : AT (_textLMA)
  {
    _wherestext2 = .;
    *(.text)
    etc.

However, the text section isn't being located correctly.  If I set
_traps_ram=1, and _exec_rom=0, I get :-

Idx Name          Size      VMA       LMA       File off  Algn
  0 .crttext      000014a8  00000000  00000000  00010000  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .text         00009b60  40000000  000014a8  00020000  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, CODE

(crttext is a boot section which contains the ROM trap table and basic
boot code)

Even stranger, the two "wheres..." debug symbols I added have the
following values :-

40001000 g       .text 00000000 _wherestext1
40000000 g       .text 00000000 _wherestext2

Reading the manual, I understand that LD uses "lazy evaluation" for
expressions, but this is just baffling me - it does seem to have the
correct value somewhere internally, it just isn't using it for the
section address.  Substituting "_textVMA" or "_wherestext1" for the
"." in the section definition doesn't work either, which is even more
puzzling.

Any ideas or suggestions would be appreciated, as this is slowly
driving me mad... :-)

Regards,

David P.

Re: LD scripts - using expressions correctly

[Alan Modra]

On Mon, Jul 07, 2014 at 02:21:17PM +0100, David Paterson wrote:
> Any ideas or suggestions would be appreciated, as this is slowly
> driving me mad... :-)

Try current mainline binutils.

-- 
Alan Modra
Australia Development Lab, IBM

Re: LD scripts - using expressions correctly

[David Paterson]

Thanks Alan,

I should have mentioned I'm using 2.24, but I'll pull the latest
version from GIT and try that.

Cheers,

David P.


On 7 July 2014 14:56, Alan Modra <amodra@gmail.com> wrote:
> On Mon, Jul 07, 2014 at 02:21:17PM +0100, David Paterson wrote:
>> Any ideas or suggestions would be appreciated, as this is slowly
>> driving me mad... :-)
>
> Try current mainline binutils.
>
> --
> Alan Modra
> Australia Development Lab, IBM

Re: LD scripts - using expressions correctly

[Alan Modra]

On Mon, Jul 07, 2014 at 03:06:45PM +0100, David Paterson wrote:
> I should have mentioned I'm using 2.24, but I'll pull the latest
> version from GIT and try that.

If mainline works for you, then I expect fa72205c was the patch that
fixed your trouble.  Which also means you can work around this by
replacing:

  _textVMA = (_exec_rom > 0) ? _textLMA : _ram_start;
  _textVMA += _textoffset;

with:

  _textVMA = ((_exec_rom > 0) ? _textLMA : _ram_start) + _textoffset;

-- 
Alan Modra
Australia Development Lab, IBM

Re: LD scripts - using expressions correctly

[David Paterson]

Thanks.  I'm building at the moment and should be able to test that in
a little while :-)


On 7 July 2014 15:36, Alan Modra <amodra@gmail.com> wrote:
> On Mon, Jul 07, 2014 at 03:06:45PM +0100, David Paterson wrote:
>> I should have mentioned I'm using 2.24, but I'll pull the latest
>> version from GIT and try that.
>
> If mainline works for you, then I expect fa72205c was the patch that
> fixed your trouble.  Which also means you can work around this by
> replacing:
>
>   _textVMA = (_exec_rom > 0) ? _textLMA : _ram_start;
>   _textVMA += _textoffset;
>
> with:
>
>   _textVMA = ((_exec_rom > 0) ? _textLMA : _ram_start) + _textoffset;
>
> --
> Alan Modra
> Australia Development Lab, IBM

Re: LD scripts - using expressions correctly

[David Paterson]

Hmmm, build failure :-

.../libiberty/fibheap.c:38:24: error: 'LONG_MIN
' undeclared (first use in this function)
 #define FIBHEAPKEY_MIN LONG_MIN

 I'm not sure if it's something wrong in my build environment (MinGW)
or my configure settings, or something else, but I'll perhaps try
working back to earlier versions and see how it goes.

AT least I know there's likely a fix for my original problem.

DP


On 7 July 2014 15:46, David Paterson <dnpaterson@gmail.com> wrote:
> Thanks.  I'm building at the moment and should be able to test that in
> a little while :-)
>
>
> On 7 July 2014 15:36, Alan Modra <amodra@gmail.com> wrote:
>> On Mon, Jul 07, 2014 at 03:06:45PM +0100, David Paterson wrote:
>>> I should have mentioned I'm using 2.24, but I'll pull the latest
>>> version from GIT and try that.
>>
>> If mainline works for you, then I expect fa72205c was the patch that
>> fixed your trouble.  Which also means you can work around this by
>> replacing:
>>
>>   _textVMA = (_exec_rom > 0) ? _textLMA : _ram_start;
>>   _textVMA += _textoffset;
>>
>> with:
>>
>>   _textVMA = ((_exec_rom > 0) ? _textLMA : _ram_start) + _textoffset;
>>
>> --
>> Alan Modra
>> Australia Development Lab, IBM

Re: LD scripts - using expressions correctly

[David Paterson]

OK - I have no idea why I can't get it to build (HAVE_LIMITS_H is
definitely defined via the configure step) but that's a problem for
another thread.

Re the expressions problem, I tried using Alan's re-written version
and it works perfectly when using the current version (2.24) of
Binutils.  A bit of experimenting seems to show that it's the "+="
operator that's up to mischief so I've removed all uses of it from my
scripts, and they're working fine now.

Thanks to Alan for his help, and remember folks, when using LD, just
say "No!" to += :-)

Cheers,

David P.

On 7 July 2014 16:10, David Paterson <dnpaterson@gmail.com> wrote:
> Hmmm, build failure :-
>
> .../libiberty/fibheap.c:38:24: error: 'LONG_MIN
> ' undeclared (first use in this function)
>  #define FIBHEAPKEY_MIN LONG_MIN
>
>  I'm not sure if it's something wrong in my build environment (MinGW)
> or my configure settings, or something else, but I'll perhaps try
> working back to earlier versions and see how it goes.
>
> AT least I know there's likely a fix for my original problem.
>
> DP
>
>
> On 7 July 2014 15:46, David Paterson <dnpaterson@gmail.com> wrote:
>> Thanks.  I'm building at the moment and should be able to test that in
>> a little while :-)
>>
>>
>> On 7 July 2014 15:36, Alan Modra <amodra@gmail.com> wrote:
>>> On Mon, Jul 07, 2014 at 03:06:45PM +0100, David Paterson wrote:
>>>> I should have mentioned I'm using 2.24, but I'll pull the latest
>>>> version from GIT and try that.
>>>
>>> If mainline works for you, then I expect fa72205c was the patch that
>>> fixed your trouble.  Which also means you can work around this by
>>> replacing:
>>>
>>>   _textVMA = (_exec_rom > 0) ? _textLMA : _ram_start;
>>>   _textVMA += _textoffset;
>>>
>>> with:
>>>
>>>   _textVMA = ((_exec_rom > 0) ? _textLMA : _ram_start) + _textoffset;
>>>
>>> --
>>> Alan Modra
>>> Australia Development Lab, IBM