------- Additional Comments From amodra at bigpond dot net dot au 2005-06-09
06:29 -------
This is a consequence of the way gas resolves symbols. The problem is that the
first assignment to msglen isn't resolved immediately when parts of the
expression use symbols ("." and "msg" here) in different frags. A frag is a
chunk of code/data being assembled, with a fixed part and a variable part.
Because gas knows that frags might have a variable part, it leaves such
expressions for later evaluation, after all frags have their variable parts
fixed. Thus the second assignment to msglen also can't be evaluated
immediately, and gas simply sets the value of msglen to "msglen & 0xff", exactly
as would be done if the first assignment had never been encountered. Which
results in a symbol definition loop.
The reason that -a causes the failure is that turning on listings employs a hack
where a frag is allocated for each line. However, this can happen without -a if
a new frag is needed for some other reason.
I see a number of possible solutions, all of which I'm disinclined to implement
myself.
1) Rewrite gas listing code to do without frags, possibly combined with
2) Modify gas symbol evaluation code to allow immediate subtraction of symbols
in different frags if all intervening frags are fixed in size.
3) Have gas generate multiple versions of symbols.
(3) is probably the easiest to implement. You can do it yourself at the user
level, of course:
msg: .asciz "hello world.\n"
x = .-msg-1
msglen=x & 0xff
--
http://sources.redhat.com/bugzilla/show_bug.cgi?id=997
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
