[RFC] ARM merging symbols bugs

[Paul Brook <paul at codesourcery dot com>]

On ARM ELF targets there are two different types of function symbols, STT_FUNC 
and STT_ARM_TFUNC. These effect the behavior of certain relocations, but are 
otherwise identical. The on-disk representation of these symbols varies, but 
internally we use use STT_ARM_TFUNC for Thumb function symbols.

The problem is that there are several places in elflink.c that explicitly test 
for STT_FUNC. In addition _bfd_elf_merge_symbol contains logic to
"skip it if its type and the type of existing regular definition mismatch".
I haven't audited the generic ELF code thoroughly, so there may be other 
instances of these bugs.

I can see two possible solutions to this:

1) Change the ARM code to always use STT_FUNC, and represent Thumbness some 
other way. This would require a moderate amount of work in elf32-arm.c, and a 
fair chance of breaking something in the process. I don't know if there's any 
convenient place to hang the type annotation onto the symbol.

2) Add elf backend hooks for symbol_type_conflicts and is_function_symbol. 
Fairly easy to implement and a very low chance of breaking everything, but 
introduces uglyness into the generic ELF code.

Thoughts or suggestions?


The attached files are a reduced testcase from the g++ testsuite. It involves 
an executable overriding a symbol defined in a shared library. Build with the 
following commands:

arm-linux-gnueabi-as lib.s -o lib.o
arm-linux-gnueabi-as main-thumb.s -o main-thumb.o
arm-linux-gnueabi-ld -shared lib.o -o lib.so --version-script lib.ver
arm-linux-gnueabi-ld main-thumb.o lib.so

Note that foo is not in the dynamic symbol table of the executable. Replace 
main-thumb with main-arm and it works correctly.

Paul

Attachment: main-thumb.s
Description: Text document

Attachment: main-arm.s
Description: Text document

Attachment: lib.s
Description: Text document

Attachment: lib.ver
Description: Text document