ARM: handling of weak symbols in thumb code

ARM: handling of weak symbols in thumb code

[Adrian von Bidder]

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

Re: ARM: handling of weak symbols in thumb code

[Nick Clifton]

Hi Adrian,

> 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 even though (i) __init_stdio is, as
> mentioned, not present at all,

Are you really sure ?  The function in the linker that decides if an
interworking stub is necessary is bfd/elf32-arm.h:bfd_elf_arm_process_
before_allocation().  This scans the incoming bfd and looks are
function call relocs.  It then loads the symbol for the destination of
the call and checks to see if it is in a different mode from the
caller.

Given this, the presence of the __init_stdio interworking stub in your
output file would imply that a) there is an R_ARM_THM_PC22 reloc
against the symbol __init_stdio somewhere in your input files and b)
that the symbol __init_stdio is defined as a type other that
STT_ARM_TFUNC in one of the input file's symbol tables.

It is possible that there is a discarding issue here.  ie the stub is
being generated before the linker decides to discard the relevant
section(s)...


> (ii) the __init_stdio that *would* be called is really a thumb
> function

Well the linker is not psychic, so it cannot know this. :-)

> and (iii) I nowhere used any of
> -mthumb-interwork or -mcalle?-super-interworking. 

Interworking stub generation by the linker is automatic, it does not
depend upon the presence of any flags passed to the compiler.  Of
course if you do not enable interworking or super-interworking then
the stubs alone will not be sufficient to make the resulting
executable correct, but that is another problem.



> 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)

Some other file must also be defining the symbol.  Check your other
input files and libraries.

Cheers
        Nick

Re: ARM: handling of weak symbols in thumb code

[Adrian von Bidder]

On Wed, 2002-01-09 at 12:28, Nick Clifton wrote:
> > 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 even though (i) __init_stdio is, as
> > mentioned, not present at all,

[...]

> Given this, the presence of the __init_stdio interworking stub in your
> output file would imply that a) there is an R_ARM_THM_PC22 reloc
> against the symbol __init_stdio somewhere in your input files and b)
> that the symbol __init_stdio is defined as a type other that
> STT_ARM_TFUNC in one of the input file's symbol tables.

Hi again,

From my original mail:
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

These are the occurrencies of __init_stdio in the symbol tables. The
conditional call is if (__init_stdio) __init_stdio(), so the entry in
.rodata contains the function pointer.

I suspect that either the linker assumes that function pointers point to
ARM functions, or that the WEAK/NOTYPE in the symtab confuses the linker
and causes it to assume that init_stdio would be resolved to an ARM
symbol.

greets from Zürich
-- vbi

Re: ARM: handling of weak symbols in thumb code

[Nick Clifton]

Hi Adrian,

> I suspect that either the linker assumes that function pointers
> point to ARM functions, or that the WEAK/NOTYPE in the symtab
> confuses the linker and causes it to assume that init_stdio would be
> resolved to an ARM symbol.

Probably. :-)  I am sorry - I am very busy right now so I do not have
time to investigate this bug, but if you want to have a go please do.

Cheers
        Nick