Re: ARM: handling of weak symbols in thumb code

[Adrian von Bidder <avbidder at acter dot ch>]

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