https://sourceware.org/bugzilla/show_bug.cgi?id=21703
Bug ID: 21703
Summary: The first symbol definition is overwritten by second
definition when --allow-multiple-definition is
provieded
Product: binutils
Version: 2.29 (HEAD)
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: renlin.li at arm dot com
Target Milestone: ---
I am investigating some arm regressions on gcc trunk.
There are other issues around those LTO test cases.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78529
Apart from the gcc lto issues, I noticed a new issues which I believe is bfd
linker's problem. so I opened this separate bugzilla ticket.
The cases are quit tricky.
With user-defined library function and lto optimization, the compiler optimize
the code with the knowledge of user-defined function, while linking with
library defined function.
The user defined function is abandoned.
The issues in gcc is that, the register usage of library function
implementation is different from the user defined function. This will cause
runtime error.
For arm target, there is another type of error. For example,
gcc/testsuite/gcc.c-torture/execute/builtins/strlen-2.c
The library implementation of strlen function is a thumb function while the
user-defined one is in arm mode.
Normally, a BL instruction is generated for the function call. Later, it's the
linker who changed the BL into BLX if the destination of function call is a
thumb function.
The error is that, while linking with library defined function, the BL
instruction is not
converted into BLX given the fact that the destination is a thumb function.
The symbol is over-written by the user define function. And the size of the
symbol is not the size of actual linked function.
I checked the documentation of --allow-multiple-definition option,
'''Normally when a symbol is defined multiple times, the linker will report a
fatal error. These options allow multiple definitions and the first definition
will be used.'''
The first definition is from the library, and the second one is from user
defined code. This is the order the linker scans the object files.
Following the document, apparently, the symbol shouldn't be overwritten.
I assume this is a stand-alone bfd linker bug.
I have debugged a little bit. in elf_link_add_object_symbols ()
_bfd_elf_merge_symbol() will be called to decided what is going to do if there
is already a symbol in the hash table.
and _bfd_generic_link_add_one_symbol() will do something to actually add the
symbol to the global hash table.
However, _bfd_generic_link_add_one_symbol() will do nothing if it is a multiple
definition, while _bfd_elf_merge_symbol() decided the override the existing
symbol with the new definition.
_bfd_elf_merge_symbol() returns a OVERRIDE flag which indicates whether the old
definition should override the new definition. To me, it seems OVERRIDE should
be TRUE for this case. If their is an old definition and
allow_multiple_definition is true, the function will return TRUE with OVERRIDE
set to TRUE.
But there are a lot of other cases in the function, I don't know if I have
missed anything.
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
