This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: .align/multiple .set bug
- From: Nick Clifton <nickc at redhat dot com>
- To: josh at qualdan dot com
- Cc: binutils at sources dot redhat dot com
- Date: Tue, 20 Jul 2004 13:26:37 +0100
- Subject: Re: .align/multiple .set bug
- References: <20040716005027.GA20874@qualdan>
Hi Joseph,
.macro list_entry
.int _start+link
.set link,.-_start
.endm
.set link,0
.text
_start:
list_entry
list_entry
list_entry
list_entry
.balign 4
list_entry
list_entry
At any rate, this should produce a list of 8 32-bit values, each being
the address of the previous value. I.e. 0, 4, 8, ... 0x18, 0x1c.
Note - if you really wanted that, then your macro should have been this:
.macro list_entry
.int _start + link
.set link,(. - _start) - 4
since you want "link" to store the offset to the ".int" instruction
which you have just generated. Anyway...
Instead, the first time the symbol is set after the .balign pseudo-op,
it gets some unexpected value.
> My best guess at the moment is that the alignment directives reset
the > current location counter to zero, or something like that.
It is actually quite complicated, but effectively yes, this is what is
happening. There is a relatively easy workaround for the problem
however - local labels. Try this version of your test code:
.macro list_entry
.int 1b - 4
1:
.endm
.text
_start:
1:
list_entry
list_entry
list_entry
list_entry
.balign 4
nop
list_entry
list_entry
list_entry
list_entry
I added the "nop" to demonstrate that the generated list addresses
really do refer back to the previous list entry and not just the
previous instruction of any kind.
This file produces the following disassembly:
0: ff ff ff fc fnmsub f31,f31,f31,f31
4: 00 00 00 00 .long 0x0
8: 00 00 00 04 .long 0x4
c: 00 00 00 08 .long 0x8
10: 60 00 00 00 nop
14: 00 00 00 0c .long 0xc
18: 00 00 00 14 .long 0x14
1c: 00 00 00 18 .long 0x18
20: 00 00 00 1c .long 0x1c
Cheers
Nick