From: "Doug Kwan (關振德)" <dougkwan@google.com>
To: Ian Lance Taylor <iant@google.com>
Cc: binutils <binutils@sourceware.org>
Subject: Re: [GOLD][PATCH] Set SHF_LINK_ORDER flags of ARM EXIDX sections.
Date: Tue, 19 Oct 2010 18:54:00 -0000 [thread overview]
Message-ID: <AANLkTik=R4J-9eVopOROW6-t0S+UkCNp=0sAHRMpnOx4@mail.gmail.com> (raw)
In-Reply-To: <mcrsk029l9r.fsf@google.com>
[-- Attachment #1: Type: text/plain, Size: 2829 bytes --]
Here is a revised patch.
-Doug
2010-10-19 Doug Kwan <dougkwan@google.com>
* arm.cc (Target_arm::do_finalize_sections): Force SHF_LINK_ORDER
flag in section headers of EXIDX sections in a relocatable link.
* output.cc (Output_section::Output_section): Initialize member
force_link_order_.
* output.h (Output_section::force_link_order): New method.
(Output_section::set_force_link_order): Ditto.
(Output_section::force_link_order_): New data member.
在 2010年10月20日上午12:53,Ian Lance Taylor <iant@google.com> 寫道:
> "Doug Kwan (關振德)" <dougkwan@google.com> writes:
>
>> Gold does not handle SHF_LINK_ORDER flag in general, we drop the flag
>> when searching for an output section.
>>
>> Output_section*
>> Layout::choose_output_section(const Relobj* relobj, const char* name,
>> elfcpp::Elf_Word type, elfcpp::Elf_Xword flags,
>> bool is_input_section, Output_section_order order,
>> bool is_relro)
>> ...
>>
>> // Some flags in the input section should not be automatically
>> // copied to the output section.
>> flags &= ~ (elfcpp::SHF_INFO_LINK
>> | elfcpp::SHF_LINK_ORDER
>> | elfcpp::SHF_GROUP
>> | elfcpp::SHF_MERGE
>
> Oh yeah, sorry about that.
>
> That is incorrect when generating relocatable output. Rather than
> testing for SHT_ARM_EXIDX in the target-independent code, suppose we add
> another bit flag to Output_section. Then we can set it if
> SHF_LINK_ORDER is set in the input section, which will be correct once
> we finally support SHF_LINK_ORDER. And the ARM backend can set it at
> will.
>
> Ian
>
>> 在 2010年10月19日下午10:07,Ian Lance Taylor <iant@google.com> 寫道:
>>> "Doug Kwan (關振德)" <dougkwan@google.com> writes:
>>>
>>>> This patch changes code writing output section headers so that the
>>>> SHF_LINK_ORDER flag of a section of type SHT_ARM_EXIDX is always set.
>>>> The flag is required to be set for such a section by the ARM EHABI.
>>>> The existing code drops the SHF_LINK_ORDER flag and that confuses
>>>> other tools. Gold does not handle SHF_LINK_ORDER in general but the
>>>> ARM back-end can handle the EXIDX sections.
>>>>
>>>> -Doug
>>>>
>>>>
>>>> 2010-10-19 Doug Kwan <dougkwan@google.com>
>>>>
>>>> * output.cc(Output_section::write_header): Set SHF_LINK_ORDER flags of
>>>> ARM EXIDX sections.
>>>
>>> I don't see the ARM backend actually creating any SHT_ARM_EXIDX
>>> sections. So it seems to me that they are input sections. If the ABI
>>> requires the input sections to have the SHF_LINK_ORDER flag set, then
>>> that setting should carry through to the output section. Does that not
>>> happen?
>>>
>>> Ian
>>>
>
[-- Attachment #2: patch-link-order.txt --]
[-- Type: text/plain, Size: 2786 bytes --]
Index: gold/arm.cc
===================================================================
RCS file: /cvs/src/src/gold/arm.cc,v
retrieving revision 1.124
diff -u -u -p -r1.124 arm.cc
--- gold/arm.cc 17 Oct 2010 15:12:50 -0000 1.124
+++ gold/arm.cc 19 Oct 2010 18:37:01 -0000
@@ -8497,6 +8497,9 @@ Target_arm<big_endian>::do_finalize_sect
Arm_output_section<big_endian>* os =
Arm_output_section<big_endian>::as_arm_output_section(*p);
os->set_exidx_section_link();
+ // Make sure SHF_LINK_ORDER flag is set.
+ if (parameters->options().relocatable())
+ os->set_force_link_order(true);
}
}
Index: gold/output.cc
===================================================================
RCS file: /cvs/src/src/gold/output.cc,v
retrieving revision 1.136
diff -u -u -p -r1.136 output.cc
--- gold/output.cc 18 Oct 2010 05:39:23 -0000 1.136
+++ gold/output.cc 19 Oct 2010 18:37:01 -0000
@@ -2005,7 +2005,8 @@ Output_section::Output_section(const cha
always_keeps_input_sections_(false),
tls_offset_(0),
checkpoint_(NULL),
- lookup_maps_(new Output_section_lookup_maps)
+ lookup_maps_(new Output_section_lookup_maps),
+ force_link_order_(false)
{
// An unallocated section has no address. Forcing this means that
// we don't need special treatment for symbols defined in debug
@@ -3091,6 +3092,8 @@ Output_section::write_header(const Layou
elfcpp::Elf_Xword flags = this->flags_;
if (this->info_section_ != NULL && this->info_uses_section_index_)
flags |= elfcpp::SHF_INFO_LINK;
+ if (this->force_link_order_)
+ flags |= elfcpp::SHF_LINK_ORDER;
oshdr->put_sh_flags(flags);
oshdr->put_sh_addr(this->address());
Index: gold/output.h
===================================================================
RCS file: /cvs/src/src/gold/output.h,v
retrieving revision 1.115
diff -u -u -p -r1.115 output.h
--- gold/output.h 18 Oct 2010 05:39:23 -0000 1.115
+++ gold/output.h 19 Oct 2010 18:37:01 -0000
@@ -3314,6 +3314,16 @@ class Output_section : public Output_dat
void
print_merge_stats();
+ // Whether we always set SHF_LINK_ORDER in section header.
+ bool
+ force_link_order() const
+ { return this->force_link_order_; }
+
+ // Force setting SHF_LINK_ORDER in output section header.
+ void
+ set_force_link_order(bool value)
+ { this->force_link_order_ = value; }
+
protected:
// Return the output section--i.e., the object itself.
Output_section*
@@ -3765,6 +3775,8 @@ class Output_section : public Output_dat
Checkpoint_output_section* checkpoint_;
// Fast lookup maps for merged and relaxed input sections.
Output_section_lookup_maps* lookup_maps_;
+ // Force SHF_LINK_ORDER in section header.
+ bool force_link_order_;
};
// An output segment. PT_LOAD segments are built from collections of
next prev parent reply other threads:[~2010-10-19 18:54 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-19 8:17 Doug Kwan (關振德)
2010-10-19 14:08 ` Ian Lance Taylor
2010-10-19 16:12 ` Doug Kwan (關振德)
2010-10-19 16:33 ` Cary Coutant
2010-10-19 16:52 ` Doug Kwan (關振德)
2010-10-19 16:54 ` Ian Lance Taylor
2010-10-19 18:54 ` Doug Kwan (關振德) [this message]
2010-10-19 19:29 ` Ian Lance Taylor
[not found] ` <AANLkTimBgvCfeY3gTPV8UkUPH2igcmhzd=LJDVF5gRgd@mail.gmail.com>
2010-10-19 20:29 ` Ian Lance Taylor
[not found] ` <AANLkTi=4DTSjUz5HCbU8uARWHEd8Deh3jhFYgrxqpaU2@mail.gmail.com>
2010-10-20 10:39 ` Doug Kwan (關振德)
2010-10-20 14:54 ` Ian Lance Taylor
2010-10-20 17:41 ` Cary Coutant
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='AANLkTik=R4J-9eVopOROW6-t0S+UkCNp=0sAHRMpnOx4@mail.gmail.com' \
--to=dougkwan@google.com \
--cc=binutils@sourceware.org \
--cc=iant@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).