feat: add __executable_start
#1257
Conversation
| ty: sht::PROGBITS, | ||
| section_flags: shf::ALLOC.with(shf::EXECINSTR), | ||
| start_symbol_name: Some(EXECUTABLE_START), | ||
| ..DEFAULT_DEFS |
There was a problem hiding this comment.
This is wrong because that symbols should be emitted only for (some kinds of?) executables. Probably should be created inside Prelude::new.
Similarly, Wild outputs __ehdr_start even when other linkers don't, and it also misses __dso_handle symbol.
There was a problem hiding this comment.
I haven't looked into this too much, but a couple of things that you were probably aware of, but just in case... some of these symbols are PROVIDE in the GNU ld linker script, which AFAIK means that the linker script should only define the symbol if it's referenced and not defined by anything input objects. We don't yet support PROVIDE semantics, although it might be being worked on - #1097.
Some flags can affect the built-in linker script that GNU ld uses. You can see what changes for some particular flag with a command like meld <(ld --verbose) <(ld --pie --verbose).
There was a problem hiding this comment.
Thanks, I didn't see your comment when I was writing the other one (GitHub didn't refresh automatically). Well, I was unaware but figured that out eventually.
|
Quick update: With the latest change, eyra now passes many more tests and |
| pub(crate) link: &'static [OutputSectionId], | ||
| pub(crate) start_symbol_name: Option<&'static str>, | ||
| pub(crate) end_symbol_name: Option<&'static str>, | ||
| pub(crate) synthetic_symbol_names: Option<&'static [&'static str]>, |
There was a problem hiding this comment.
Is there intended to be a difference between None and Some(&[]) here? If not, then we could get rid of the Option.
Is this intended to be different to start_symbol_name? i.e. is this supposed to be start-symbols that have provide-semantics? I'm unsure about the naming, since these symbols seem just as synthetic as the start/end symbols. I guess until such time as we support provide-semantics, one option would be to change start_symbol_name: Option<&'static str>tostart_symbol_names: &'static [&'static str]. Then, once we support provide-semantics, split it out into two separate fields. e.g. start_symbol_namesandprovide_start_symbol_names` or something like that.
There was a problem hiding this comment.
That was just a proof of concept because I'm not sure whether it's worth doing it.
The only difference from start symbols is the fact they shouldn't be provided by default, but it's not fulfilled yet.
The naming is based on LLD. I tried to find any docs regarding what those symbols are and LLD comments are probably the best (at least they exist). There I noticed they are referred as synthetic symbols. I'm not happy with that name though.
The next release is probably far away, so we can wait for provide. I don't think this is something of high priority.
2 participants
cc #1096