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: forward references in equates


On Fri, Sep 16, 2005 at 01:58:19PM +0200, Jan Beulich wrote:
> 
>  .equiv two, 2*one
>  .equ one, 1
>  .equiv three, 3*one
> 
>  .data
> 
> 	.byte	one
> 	.byte	two
> 	.byte	three

I'd be reasonably confortable if gas gave 1, 2, 3 for the above,

>  .equ one, -1
> 	.byte	one
> 	.byte	two
> 	.byte	three

but what should these be?  I'd be inclined to say -1, 2, 3.  Are you
proposing that the last three values be -1, -2, -3?  That would be
changing the meaning of .equiv, I think.

> without the change the value stored for 'two' in both instances was
> 0xFE (the final value), while with the change it is now in both cases
> 0x02 (the value derived with the first setting of 'one').

Certainly, the current gas behaviour of giving -2 for both instances of
"two" is counter-intuitive.

> It seems clear
> to me that only the snapshotting-the-expression approach can address
> this.

I don't think taking a snapshot of the expression is correct.  It's
obviously wrong for an expresion that is undefined at the point where it
is used, for example:

str1:
 .byte len
 .ascii "pascal style string"
len = . - str1 - 1

[snip]
>  .equiv x, y-z
>  .equiv x, 1
> 
> gas would not report a redefinition of x, since for expressions used as
> the assigned values the symbol gets set to undefined_section rather than
> expr_section. Changing this fixes this problem and also doesn't, for
> x86, show any other regressions in the testsuite, but I'm a little
> worried that there might be dependencies on undefined_section being used
> in this case somewhere. Should I still submit a patch for that (and
> leave it to the future to locate any potential problems resulting from
> that), or do you have an idea how the safeness of such a change could be
> proven and/or why undefined_section was used there in the first place
> (introduced by you in 1.95/1.94.2.1)?

Prior to that patch, ".set x, y-z" left the segment of x as it was
prior to the assignment.  On the first assignment to x, this was
undefined_section.  On subsequent assignments it was dependent on the
previous value, which is obviously wrong.  I just changed it so that all
assignments were the same as the first.  ie. I didn't introduce the use
of undefined_section with that particular patch, nor did I analyse
whether undefined_section in fact is correct.  Using expr_section is
probably better.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre


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