This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
.align/multiple .set bug
- From: josh at qualdan dot com
- To: binutils at sources dot redhat dot com
- Date: Thu, 15 Jul 2004 20:50:27 -0400
- Subject: .align/multiple .set bug
I was playing with assembly language the other day, and ran across what
seems to be a bug in gas. .align messes up symbols created with .set,
at least sometimes. I was trying to define data that was linked
together in a list.
I'm running:
GNU assembler 2.15.90.0.3 20040415
On a powerpc-unknown-linux-gnu (dual-G4 running Gentoo).
--------------------------------
.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
list_entry
list_entry
--------------------------------
Note that it is necessary to define link relative to _start. If you
just do '.set link,.', gas produces a symbol 'link' in the relocatable
ELF file, and thus all entries are given the same value.
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.
Instead, the first time the symbol is set after the .balign pseudo-op,
it gets some unexpected value.
Here is the output from `objdump -d` and `objdump -r`. I marked the
location of the .balign directive.
--------------------------------
set.o: file format elf32-powerpc
Disassembly of section .text:
00000000 <_start>:
0: 00 00 00 00 .long 0x0
4: 00 00 00 04 .long 0x4
8: 00 00 00 08 .long 0x8
c: 00 00 00 0c .long 0xc
.balign 4
10: 00 00 00 10 .long 0x10
14: 00 00 00 04 .long 0x4
18: 00 00 00 08 .long 0x8
1c: 00 00 00 0c .long 0xc
--------------------------------
00000000 R_PPC_ADDR32 _start
00000004 R_PPC_ADDR32 _start+0x00000004
00000008 R_PPC_ADDR32 _start+0x00000008
0000000c R_PPC_ADDR32 _start+0x0000000c
00000010 R_PPC_ADDR32 _start+0x00000010
00000014 R_PPC_ADDR32 _start+0x00000004
00000018 R_PPC_ADDR32 _start+0x00000008
0000001c R_PPC_ADDR32 _start+0x0000000c
--------------------------------
At first, I thought that the symbol reverted to its first "relative"
value -- it doesn't affect things like '.set link,0x74'. But that
doesn't quite fit. My best guess at the moment is that the alignment
directives reset the current location counter to zero, or something like
that.
--Josh