public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
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

  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).