aboutsummaryrefslogtreecommitdiff
path: root/gold/script-sections.cc
diff options
context:
space:
mode:
authorCary Coutant <ccoutant@gmail.com>2015-06-03 19:11:42 -0700
committerCary Coutant <ccoutant@gmail.com>2015-06-03 19:37:49 -0700
commit374082dfab280123f5a54a23b1c1b2cb893b4d2b (patch)
treeee46d25beff71515f332061bc9865c0ab5c822db /gold/script-sections.cc
parenta96a7cce1820951c566cfe793ccc72db1e4adf69 (diff)
downloadgdb-374082dfab280123f5a54a23b1c1b2cb893b4d2b.zip
gdb-374082dfab280123f5a54a23b1c1b2cb893b4d2b.tar.gz
gdb-374082dfab280123f5a54a23b1c1b2cb893b4d2b.tar.bz2
Fix gold to group sections correctly via linker script.
In PR 15370, it is noted that gold does not distinguish between "*(.foo .bar)" and "*(.foo) *(.bar)" in linker scripts. In both cases, gold groups all .foo sections together, followed by all .bar sections, whereas in the first case, it should collect all .foo and .bar sections in the order seen. If you add sort specs, the Gnu linker has some bizarre corner cases that I do not try to replicate. In particular, "*(SORT_BY_NAME(.foo) SORT_BY_NAME(.bar))" does the same thing as "*(.foo) *(.bar)". But if you apply a sort spec to just one of several patterns, say, "*(SORT_BY_NAME(.foo) .bar)", the Gnu linker will collect any .bar section it sees before the first .foo, then all .foo sections, then all remaining .bar sections. With this patch, if any of the input patterns have a sort spec, gold will group them all as it did before; e.g., all .foo sections followed by all .bar sections. 2015-06-03 Cary Coutant <ccoutant@gmail.com> gold/ PR gold/15370 * script-sections.cc (Output_section_element_input::set_section_addresses): When there are several patterns with no sort spec, put all sections in the same bin. * testsuite/Makefile.am (script_test_12): New testcase. (script_test_12i): New testcase. * testsuite/Makefile.in: Regenerate. * testsuite/script_test_12.t: New test linker script. * testsuite/script_test_12i.t: New test linker script. * testsuite/script_test_12a.c: New test source file. * testsuite/script_test_12b.c: New test source file.
Diffstat (limited to 'gold/script-sections.cc')
-rw-r--r--gold/script-sections.cc28
1 files changed, 27 insertions, 1 deletions
diff --git a/gold/script-sections.cc b/gold/script-sections.cc
index 9ff0fee..4f29c08 100644
--- a/gold/script-sections.cc
+++ b/gold/script-sections.cc
@@ -1555,9 +1555,33 @@ Output_section_element_input::set_section_addresses(
// We build a list of sections which match each
// Input_section_pattern.
+ // If none of the patterns specify a sort option, we throw all
+ // matching input sections into a single bin, in the order we
+ // find them. Otherwise, we put matching input sections into
+ // a separate bin for each pattern, and sort each one as
+ // specified. Thus, an input section spec like this:
+ // *(.foo .bar)
+ // will group all .foo and .bar sections in the order seen,
+ // whereas this:
+ // *(.foo) *(.bar)
+ // will group all .foo sections followed by all .bar sections.
+ // This matches Gnu ld behavior.
+
+ // Things get really weird, though, when you add a sort spec
+ // on some, but not all, of the patterns, like this:
+ // *(SORT_BY_NAME(.foo) .bar)
+ // We do not attempt to match Gnu ld behavior in this case.
+
typedef std::vector<std::vector<Input_section_info> > Matching_sections;
size_t input_pattern_count = this->input_section_patterns_.size();
- if (input_pattern_count == 0)
+ bool any_patterns_with_sort = false;
+ for (size_t i = 0; i < input_pattern_count; ++i)
+ {
+ const Input_section_pattern& isp(this->input_section_patterns_[i]);
+ if (isp.sort != SORT_WILDCARD_NONE)
+ any_patterns_with_sort = true;
+ }
+ if (input_pattern_count == 0 || !any_patterns_with_sort)
input_pattern_count = 1;
Matching_sections matching_sections(input_pattern_count);
@@ -1620,6 +1644,8 @@ Output_section_element_input::set_section_addresses(
++p;
else
{
+ if (!any_patterns_with_sort)
+ i = 0;
matching_sections[i].push_back(isi);
p = input_sections->erase(p);
}