[WIP] consider order .init_array .fini_array#1253
[WIP] consider order .init_array .fini_array#1253YamasouA wants to merge 10 commits intodavidlattimore:mainfrom
Conversation
|
Great to see this progressing! Let me know if want any feedback yet or need any help |
|
@davidlattimore I’ve wired up the basic priority handling for .init_array / .fini_array and the legacy .ctors / .dtors, and all the unit tests are passing. I’m currently down to 6 failing integration tests, and in all of them the only remaining difference between wild and ld/lld is the order of entries in the final .init_array section (e.g. the ordering of frame_dummy, init_have_lse_atomics, ARGV_INIT_ARRAY, etc.). Right now I’m trying to match GNU ld’s behavior more precisely here – especially how it derives init priorities from section names and how it handles legacy .ctors when converting them into .init_array (including the reversal of the ctor list). I have a rough plan, but I’m still figuring out the cleanest way to express this in wild’s codebase, so if you have any suggestions or pointers on how you’d structure this logic, I’d really appreciate your feedback. |
linker-diff/src/lib.rs
Outdated
| @@ -191,8 +191,6 @@ impl Config { | |||
| ".dynamic.DT_BIND_NOW", | |||
| ".dynamic.DT_FLAGS.BIND_NOW", | |||
| // TODO: Implement proper ordering of .init .ctors etc | |||
There was a problem hiding this comment.
Can probably delete this TODO as well :)
libwild/src/elf_writer.rs
Outdated
| &mut buffers, | ||
| group.eh_frame_start_address, | ||
| ); | ||
| let mut sorted_sections = SortedSectionCollector::default(); |
There was a problem hiding this comment.
We need to sort all the .init_array sections over all the input files, but here, a new SortedSectionCollector is being created for each group. See the groups_and_buffers.into_par_iter() above. So at the moment, we'll only be sorting within a group. Which files go in which groups depends on things like the number of threads. You can force each file to be in a separate group for testing purposes by setting the environment variable WILD_FILES_PER_GROUP=1. You might find that an init-order test that passes at the moment, fails if run with this variable set.
So I think this line will need to go in the outer level of write_file_contents. That would mean that it'd need to be shareable between threads. It could either be wrapped in a Mutex or the collection could be changed to a concurrent collection like crossbeam_queue::SeqQueue. However, even that, I don't think will work because the buffers are per-group, so when you try to call sorted_sections.flush after the try_for_each has finished, you won't be able to because you don't have access to a buffer. The problem is that the buffers for .init_array etc have been allocated to each group. I think we really want one buffer for the whole .init_array section that's the right size for all of the contributions coming from different input files. Most likely that one buffer would need to be allocated to the epilogue.
One way this might be achieved is during layout, the groups from which the .init_array sections originate, rather than requesting space in the .init_array output section, could ask the epilogue or prelude to do so. One way to do this might be to add a new variant to layout::WorkItem. The epilogue when it receives a request to handle a sorted section can record information about that section, allocate space for it etc. In Epilogue::finalise_layout, we can then sort those sections by their priority. Writing the output section would then be done entirely by the epilogue.
There was a problem hiding this comment.
To add a little more detail and alternatives...
The new variant of WorkItem can probably be similar to WorkItem::LoadSection. It can probably even reuse SectionLoadRequest. e.g.`
LoadOrderedSection(SectionLoadRequest),Such requests should only be sent to the epilogue, so if a non-epilogue group receives such a request, it's fine to panic.
An alternative that might be simpler would be to add an extra field to GraphResources. That field could hold for example an OutputSectionMap<crossbeam_queue::SegQueue<SectionToSort>> or something like that. Each input file, upon finding an input section that it wants sorted could add to that queue for the relevant output section. The epilogue, probably in finalise_sizes could take those queues and allocate whatever space is needed in each sorted output section. It could do the actual sorting either in finalise_sizes or finalise_layout.
There was a problem hiding this comment.
@davidlattimore
Thank you for your advice.!!
I try to Implement GraphResources field.
libwild/src/layout.rs
Outdated
| )? { | ||
| Some(x) => x, | ||
| None => { | ||
| // Allow symbols in epilogue-owned sorted sections to be resolved later. |
There was a problem hiding this comment.
Hmm, this is tricky. I hadn't given much thought to symbols. The symbols are still owned by the object, it's just the section that is being written by the epilogue. I suspect we'd need the epilogue to determine the resolutions for the sections, then populate the relevant resolutions on the object so that the object can then resolve symbols that refer to that section. This is making me wonder if my suggestion to transfer ownership to the epilogue might have been a bad idea.
An alternative to transferring ownership would be to have multiple OutputSectionIds for .init_array, one for each used priority level. These would be merged together - see SectionKind::Secondary.
I've made a couple of refactorings that I hope would make that approach easier. It's possible that more refactorings still should be done. e.g. currently it might be a bit annoying to put __init_array_end in the correct place, although I think it should still be doable. It'd just need to be attached to the last OutputSectionId that merges into .init_array. Alternatively, we could add a second field similar to end_symbol_name, but which places the relevant symbol after any other secondary sections.
I'd be happy to go into more details if you'd like. I'm also happy to make more refactorings to make it easier.
Anyway, just know that there is an alternative if you decide that moving stuff to the epilogue is proving too difficult and sorry if I possibly sent you down the wrong path.
9bf0cad to
394fd79
Compare
davidlattimore
left a comment
There was a problem hiding this comment.
I've only skimmed over the changes so far. One thing that I wanted to check is are the tests passing for you, but failing in CI? If so, make sure you have run_all_diffs = true in your test-config.toml.
libwild/src/elf_writer.rs
Outdated
| }); | ||
| } | ||
|
|
||
| #[tracing::instrument(skip_all, name = "Sort .eh_frame_hdr")] |
There was a problem hiding this comment.
This line was removed in a separate PR. It's replaced by the timing_phase! line inside the function.
|
If you're stuck, let me know and I'll take a look through what you've got and see if I've got ideas. |
121eff5 to
ef3268e
Compare
|
@davidlattimore Details$ cargo test --profile ci --workspac Compiling libwild v0.7.0 (/workspaces/wild/libwild) Compiling wild-linker v0.7.0 (/workspaces/wild/wild) Finished `ci` profile [unoptimized] target(s) in 13.35s Running unittests src/lib.rs (target/ci/deps/libwild-05bee48f94dc9a2b)running 47 tests test result: ok. 47 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.04s running 1 test test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s running 0 tests test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s running 1 test test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s running 1 test test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s running 8 tests test result: ok. 8 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s running 0 tests test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s running 88 tests test result: ok. 88 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 21.17s Doc-tests libwild running 0 tests test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s Doc-tests linker_diff running 0 tests test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s Doc-tests linker_layout running 0 tests test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s Doc-tests linker_trace running 0 tests test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s Doc-tests linker_utils running 0 tests test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s |
|
Have you confirmed that the test configuration is specified in test output |
|
@lapla-cogito |
|
Right now the tests are failing in cases where multiple entries have the same priority. In the GCC bug below, there is a comment that says:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 To me this suggests that the behaviour for constructors with the same priority isn’t really specified. Given that, how would you prefer this to be implemented in Wild? Should we just pick a simple, deterministic rule (for example, based on object file order), or do you have a particular ordering in mind that we should try to match? |
|
Within a section, wild will write the input sections in order. That's not quite true if the input sections have different alignment, but I don't think any I did some experiments to see what the linkers were doing. Firstly, I'd suggest not worrying about order of Now, if we turn to When we run that test with your PR, we get this: I was somewhat surprised to learn that the default priority is 65535 not 0, but I guess in retrospect that actually makes sense. It looks like currently your PR isn't grouping together sections with the same priority. For example, |
|
Note that if |
libwild/src/output_section_id.rs
Outdated
There was a problem hiding this comment.
Rather than changing merging_secondary_parts, would it work to sort the secondary sections by priority here?
libwild/src/output_section_id.rs
Outdated
| #[derive(Clone, Copy, Debug, PartialEq, Eq)] | ||
| pub(crate) struct InitFiniOrder { | ||
| pub(crate) priority: u16, | ||
| pub(crate) file_index: u32, |
There was a problem hiding this comment.
I don't thing file_index should be necessary. If we just have one secondary section per used priority level, then stuff within that secondary section should naturally end up in file order.
libwild/src/resolution.rs
Outdated
| &non_dynamic.custom_sections, | ||
| non_dynamic.sections.as_mut_slice(), | ||
| ); | ||
| assign_init_fini_secondaries( |
There was a problem hiding this comment.
assign_init_fini_secondaries looks like it might be expensive. It iterates over all sections, which means we'd be iterating over all sections of all objects from a single thread.
We might be able to do something similar to how custom sections are handled. i.e. add an extra field to non_dynamic that is similar to custom_sections, but instead of a Vec<CustomSectionDetails>, a Vec of the details that we need to generate the secondary sections. i.e. the primary section ID and the priority.
Closes #588