This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Map ".text.hot" and ".text.unlikely" input section prefixes to separate output sections.


This patch fixes the problems I've been seeing. It sets the "may sort
attached input sections" flag for the .text section, which ensures
that we track all input sections for that output section. The problem
was that we can't start tracking input sections in mid-stream. We may
not want to do this unconditionally for .text, so maybe you'll want a
linker option to enable this reordering?

Ian, HJ, does this patch fix the errors you're seeing as well?

-cary


diff --git a/gold/layout.cc b/gold/layout.cc
index 62b4cad..a9583c4 100644
--- a/gold/layout.cc
+++ b/gold/layout.cc
@@ -1602,6 +1602,7 @@ Layout::make_output_section(const char* name,
elfcpp::Elf_Word type,
       && !parameters->options().relocatable()
       && (strcmp(name, ".init_array") == 0
          || strcmp(name, ".fini_array") == 0
+         || strcmp(name, ".text") == 0
          || (!parameters->options().ctors_in_init_array()
              && (strcmp(name, ".ctors") == 0
                  || strcmp(name, ".dtors") == 0))))

On Thu, Dec 20, 2012 at 2:08 PM, Cary Coutant <ccoutant@google.com> wrote:
> Here's a clue...
>
> In basic_static_test, the .init section is supposed to look like this:
>
> (gdb) disas _init
> Dump of assembler code for function _init:
>    0x00000000004002f8 <+0>:     sub    $0x8,%rsp
>    0x00000000004002fc <+4>:     callq  0x40040c <call_gmon_start>
>    0x0000000000400301 <+9>:     callq  0x4004b0 <frame_dummy>
>    0x0000000000400306 <+14>:    callq  0x4956a0 <__do_global_ctors_aux>
>    0x000000000040030b <+19>:    add    $0x8,%rsp
>    0x000000000040030f <+23>:    retq
>
> But instead it looks like this:
>
> (gdb) disas _init
> Dump of assembler code for function _init:
>    0x00000000004002f8 <+0>:     sub    $0x8,%rsp
>    0x00000000004002fc <+4>:     callq  0x40040c <check_one_fd.part.0+44>
>    0x0000000000400301 <+9>:     callq  0x4004b0 <group_number+75>
>    0x0000000000400306 <+14>:    callq  0x494720 <__do_global_ctors_aux>
>    0x000000000040030b <+19>:    add    $0x8,%rsp
>    0x000000000040030f <+23>:    retq
>
> Those first two callq instructions are jumping to the same address,
> but the targets of the calls have been moved. In fact, in the bad
> copy, the .text section has been reordered such that call_gmon_start
> is now at the very beginning of .text, but the relocation from the
> .init section didn't get adjusted, and we're jumping to where it would
> have been without the reordering.
>
> -cary
>
>
> On Thu, Dec 20, 2012 at 12:42 PM, Cary Coutant <ccoutant@google.com> wrote:
>> The failures I'm seeing with the statically-linked tests all went away
>> when I backed out this patch, but I'm not getting the internal errors
>> Ian and HJ are seeing. I'm also on Ubuntu Precise with GCC 4.6.3.
>>
>> -cary
>>
>> On Thu, Dec 20, 2012 at 12:05 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>> On Thu, Dec 20, 2012 at 12:03 PM, Ian Lance Taylor <iant@google.com> wrote:
>>>> On Wed, Dec 19, 2012 at 3:15 PM, Cary Coutant <ccoutant@google.com> wrote:
>>>>> I'm not seeing these failures either. Freshly synced to top of trunk.
>>>>
>>>> I've reproduced it on three different machines.  Synced to top of
>>>> trunk, no local changes.  Haven't had time to investigate yet.
>>>>
>>>> The key difference is probably that I am using GCC 4.6.3 on Ubuntu
>>>> Precise and Fedora 16.
>>>>
>>>
>>> Same failures on Fedora 17.
>>>
>>> --
>>> H.J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]