This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] ld: fix ABSOLUTE for general expressions


> On 19 Jul 2016, at 10:39, Alan Modra <amodra@gmail.com> wrote:
> 
> On Tue, Jul 19, 2016 at 09:06:49AM +0200, Tristan Gingold wrote:
>> 
>>> On 19 Jul 2016, at 03:02, Alan Modra <amodra@gmail.com> wrote:
>>> 
>>> On Mon, Jul 18, 2016 at 05:34:06PM +0200, Tristan Gingold wrote:
>>>> Hello,
>>>> 
>>>> it appears that ABSOLUTE(x) doesn't generate an absolute value when X is not a symbol, it looks like it works only for symbols.
>>>> See the testcase for an example.
>>> [snip]
>>>> +SECTIONS
>>>> +{
>>>> +  .text 0x100 :
>>>> +  {
>>>> +    *(.text)
>>>> +   _stack_start = ABSOLUTE(0x0800);
>>>> +  }
>>>> +}
>>> 
>>> I think what you're missing is that a plain number inside an output
>>> section statement is section relative, if the number is used as an
>>> address.
>> 
>> But, this is not what the doc says:
>> 
>> ABSOLUTE(exp)
>> Return the absolute (non-relocatable, as opposed to non-negative) value of the expression exp. Primarily useful to assign an absolute value to a symbol within a section definition, where symbol values are normally section relative.
>> 
>> I think the doc is clear, and according to it:
>> 
>> SECTIONS
>> {
>> .text 0x100 :
>> {
>>   *(.text)
>>  _stack_start = ABSOLUTE(0x0800);
>> }
>> }
>> 
>> should set _stack_start to the value 0x800 (and not 0x900).
> 
> So how would you expect the following to behave?
> 
> SECTIONS
> {
>  .text 0x100 :
>  {
>    *(.text)
>    x = 0x800;
>    y = absolute (x);
>    z = absolute (0x800);
>  }
> }
> 
> I would have thought that x, y and z should have the same value in an
> executable, and they do as shown by nm.
> 
> 0000000000000900 T x
> 0000000000000900 A y
> 0000000000000900 T z

I agree with that for x and y, but not for z.

> There *is* a bug in the section of z.  Somehow it manages to be
> section relative!  Hmm, no doubt due to premature folding of the
> expression, in exp_unop.

Yes, and that is what my patch changes.

>> I am not against allowing only symbols for operand of ABSOLUTE.  I think this would be much clearer and still backward compatible in practice.
>> 
>> The rule you gave 'a plain number inside an output section statement is section relative' is not well defined.
>> For example, how to apply it to:
>>  x = 0x80 + 4;
>> I know how ld would understand it: this is section_vma + 0x84.  But this is not exactly your rule!
> 
> In this case we have a section relative 0x80 added to a section
> relative 4, which by the odd rules regarding operations on two values
> in the same section, comes to a section relative 0x84.

I fail to draw a conclusion from your mail.  Do you agree there is a bug ?

Do you think we need to fix it (by changing the code) or do you think we need to change to doc (and only allow ABSOLUTE on symbols) ?

Tristan.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]