This is the mail archive of the
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>
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:
.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...
> My best guess at the moment is that the alignment directives reset
the > current location counter to zero, or something like that.
Instead, the first time the symbol is set after the .balign pseudo-op,
it gets some unexpected value.
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:
.int 1b - 4
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