This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Issue with --unique=.text.* on hppa
- From: Guy Martin <gmsoft at tuxicoman dot be>
- To: binutils at sourceware dot org
- Date: Wed, 15 Jan 2014 12:08:59 +0100
- Subject: Issue with --unique=.text.* on hppa
- Authentication-results: sourceware.org; auth=none
Hi,
I've been troubleshooting an issue with ld when using --unique=.text.*
and
building cmake.
When linking, multiple input files have the section .text.startup. This
particular section is not declared in the default linker script, it's
created
as an orphan section.
The function lang_place_orphans() from ld/ldlang.c marks the constraint
of the
output section as SPECIAL and one .text.startup output section is
created for
each input file containing this section.
Later, in hppaelf_add_stub_section() from ld/emultempl/hppaelf.em, the
lang_output_section_statement_type corresponding to the unique output
section created for this input section is looked up using
lang_output_section_find(). The problem with this approach is that it
will
find the first output section matching the name '.text.startup'.
Afterwards, hook_in_stub() is called from the same file and it tries to
match
any section from the lang_output_section_statement_type which
input_section match
the input section we are trying to hook (hppaelf.em:139).
This works for the first one but obviously breaks for subsequent ones
leading
to a segfault later on because some sections are not hooked up.
How should this be solved ?
- add .text.startup and other to the default linker script ?
This approach seems more like a workaround than a real fix.
- use a different way to find the correct
lang_output_section_statement_type ?
Maybe the lang_output_section_statement_type should be directly set in
the
struct asection of the input_section instead of setting
input_section->output_section and then later on find the statement
based
on the name of the output_section
Also, this behaviour seem to be the same on multiple arch (arm, aarch64,
mips, ...).
Regards,
Guy