diff options
author | Cary Coutant <ccoutant@gmail.com> | 2015-06-03 19:11:42 -0700 |
---|---|---|
committer | Cary Coutant <ccoutant@gmail.com> | 2015-06-03 19:37:49 -0700 |
commit | 374082dfab280123f5a54a23b1c1b2cb893b4d2b (patch) | |
tree | ee46d25beff71515f332061bc9865c0ab5c822db /gold/script-sections.cc | |
parent | a96a7cce1820951c566cfe793ccc72db1e4adf69 (diff) | |
download | gdb-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.cc | 28 |
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); } |