ARM THUMB_FUNC symbol type ?

[Christophe LYON]

On 23.01.2009 19:30, Daniel Jacobowitz wrote:
> On Fri, Jan 23, 2009 at 07:02:55PM +0100, Christophe LYON wrote:
>> Maybe there should be a fix in readelf/objdump so that it is more obvious 
>> to the end-user?
> 
> IMO no - we're marking things in readelf exactly the way the ABI says
> we ought.
I couldn't find the related paragraph in the ABI :-(

So you mean that the end-user is supposed to look at the LSB of a 
function address to know if it's Arm or Thumb?

 > I don't know about objdump though.  Really, I'd like
> STT_ARM_TFUNC to just go away; if we want to support it for pre-ABI
> binaries we could do it on swap-in/swap-out, like we do for EABI at
> present.
> 
>> Anyway, my original problem is that I am having a look at the mixed-app  
>> test (arm-none-eabi or arm-gnueabi-linux), where I observe that lib_func2 
>> is not of type STT_ARM_TFUNC, while I would expect  
>> elf32_arm_swap_symbol_in to have set that flag. Using readelf on  
>> mixed-lib.o says:
>>     10: 00000021     2 FUNC    GLOBAL DEFAULT    1 lib_func2
>>
>> What's wrong?
> 
> Not enough information to say - but I agree that it ought to be.
> Breakpoint on elf32_arm_swap_symbol_in and find out?
> 
I made some progress: although marked STT_ARM_TFUNC in 
elf32_arm_swap_symbol_in, it is turned to STT_FUNC in allocate_dynrelocs.

I have found that Thumb calls to ARM symbols are handled in 
elf32_arm_final_link_relocate.

This brings me to another question: on several occasions I could see 
that comment "Calls through the PLT do not require stubs". What type of 
stubs do you mean here?

Indeed, I am working on PR/9743 
http://sourceware.org/bugzilla/show_bug.cgi?id=9743, and it really seem 
to be a case where a stub is needed to reach the PLT. Just to be sure we 
  are line.

Thanks

Christophe.