This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ARM: handling of weak symbols in thumb code


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]