Mach-O: Identify sections by segment name and section name

[joanna-jo]

Mach-O sections are identified by (segment name, section name), as also seen in lld and dyld. Currently, in our implementation, we resolve Mach-O input sections by only the section name, then map each resulting OutputSectionId to a fixed output segment. This means that sections with the same section name but different segment names are coalesced together, such as __TEXT, __const and __DATA_CONST, __const.

I was looking at #1795 (cc: @marxin) and saw that the supported segments and sections were made intentionally strict though - did we want to try refactoring this now?

[davidlattimore]

Interesting. I didn't know that MachO did this. I don't see any reason why this would be better done later rather than sooner, so from my perspective, I'd say go ahead :) If there are preparatory refactorings that would help, feel free to do those first. It sounds like a challenging change to make. Good luck!

[marxin]

Bery good observation @joanna-jo! And yes, we should do the proper (segment,section) assignment as soon as possible ;) If you need a help, just ping me.

[joanna-jo]

Sounds great, thanks David and Martin! :) I'll get started working on this then.

[joanna-jo]

Hmmm just to clarify, did we want to support section identification with the fixed segments we currently have, or did we want to move onto fully supporting dynamic segment (and section) identification? I was working on a design for the latter, but I realized the way I worded this could be a little vague. If we meant the former, I can shift gears and maybe make a separate issue.

[davidlattimore]

Just so I understand, the two approaches you are talking about are:

1. Map segment name to segment ID then map (segment ID, section name) to OutputSectionId
2. Map (segment name, section name) to OutputSectionId

Is that right? Of those, the second sounds more correct, so it sounds like you're probably on the right track.

[joanna-jo]

The second option is right for section identification, but I was wondering about the adjacent problem of whether we should support arbitrary segment names:

1. Should we only support the fixed set of output segment names we currently recognize and reject all other names?
2. Or should we also create corresponding output segments as needed for segment names specified by emitted input sections?

I believe lld generally does 2, but I wasn't sure if this was out of scope for the issue?

[davidlattimore]

I'd say it depends on what it does to the size of the PR. Certainly if a PR makes two complex changes that don't need to be done in the one PR, then it would be better if those changes could be separated into two PRs. But I don't know if that's the case here. If doing 1 first, then 2 in a separate PR would just make extra work and wouldn't make reviewing simpler, then I'd say do them together. I'll defer to your judgement as to what's best.

[joanna-jo]

That makes sense, thank you! I think I was overthinking whether we wanted arbitrary segments right now or not from a design perspective, considering the port is still WIP. I'll just make two (or more) PRs for this unless we consider arbitrary segments to be big enough for its own issue.