This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
ARM: handling of weak symbols in thumb code
- From: Adrian von Bidder <avbidder at acter dot ch>
- To: binutils <binutils at sources dot redhat dot com>, gcc devel mailing list <gcc at gcc dot gnu dot org>
- Date: 09 Jan 2002 11:48:16 +0100
- Subject: ARM: handling of weak symbols in thumb code
Heyho!
Everything with binutils-2.11.2 and gcc-3.0.3 with a slightly modified
arm-linux-elf target.
I saw this in __uClibc_main.o, but I'm quite sure it's not a uClibc
issue.
__uClibc_main() calls the weak symbol __init_stdio:
weak_symbol(__init_stdio);
void __uClibc_main(/* ... */) {
/* ... */
if (__init_stdio)
__init_stdio();
/* ... */
}
seems to get everything right: readelf says
Relocation section '.rel.text' at offset 0x460 contains 6 entries:
Offset Info Type Symbol's Value Symbol's Name
00000018 00a0a R_ARM_THM_PC22 00000000 __init_stdio
Relocation section '.rel.rodata' at offset 0x498 contains 1 entries:
Offset Info Type Symbol's Value Symbol's Name
00000000 00a02 R_ARM_ABS32 00000000 __init_stdio
Symbol table '.symtab' contains 17 entries:
Num: Value Size Type Bind Vis Ndx Name
10: 00000000 0 NOTYPE WEAK DEFAULT UND __init_stdio
strange thing number one [that one is a gcc issue]:
.section .rodata
.align 2
.LC0:
.word __init_stdio
why is this in rodata? It should either be .word __init_stdio(GOT) or
(better, I think, because the code doesn't need to be changed) it should
go into .data and be relocated.
strange thing number two [probably a linker issue]:
linking a small program that calls this function and doesn't use
__init_stdio (yes, there are such programs) with flags -fpic -mthumb
produces the interworking stubs
00000138 <____init_stdio_from_thumb>:
138: 4778 bx pc
13a: 46c0 nop (mov r8, r8)
0000013c <____init_stdio_change_to_arm>:
13c: eaffffaf b 0 <_start-0x4>
even though (i) __init_stdio is, as mentioned, not present at all, (ii)
the __init_stdio that *wuold* be called is really a thumb function and
(iii) I nowhere used any of -mthumb-interwork or
-mcalle?-super-interworking.
strange thing number three [linker problem, may or may not be related]:
While linking I also get a 'Warning: type of symbol `__uClibc_main'
changed from 2 to 13 in __uClibc_main.o' even though __uClibc_main
already is a THUMB_FUNC (type 13) - readelf __uClibc_main.o says:
Symbol table '.symtab' contains 17 entries:
Num: Value Size Type Bind Vis Ndx Name
13: 00000000 60 THUMB_FUNC GLOBAL DEFAULT 1 __uClibc_main
greets from Zürich
-- vbi