ARM THUMB_FUNC symbol type ?

[Christophe LYON]

On 26.01.2009 15:42, Daniel Jacobowitz wrote:
> On Mon, Jan 26, 2009 at 01:39:55PM +0100, Christophe LYON wrote:
>> 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 :-(
> 
> AAELF section 4.5.2:
> [...]
> 
> AAELF section 4.5.3:
> 
> [...]
> 
Thanks for the clarification. The paragraphs you mention didn't catch my 
eye because I was looking for something that would say how to display 
such information.

>> 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?
> Correct.
OK. I find it a bit surprising, I would think it could be confusing for 
some casual users, but I guess it has been decided by several 
knowledgeable people ;-)

> 
>>> 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.
> 
> That should only happen if there is a PLT entry or an exported v4t
> entry stub.  When that happens the symbol is redirected to point to
> that (ARM-mode) code fragment so it is not a Thumb symbol any more.
> 
>> 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?
> 
> The stubs generated in that block are stubs to the target symbol, not
> stubs to reach the PLT.  It might require a long branch stub, but that
> comment predates long branch support :-) It won't require a
> Thumb-to-ARM stub since the PLT will contain a Thumb entry point if
> one is needed.
> 
That'is it. I am working on it.

Christophe.