<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 27, 2015 at 9:06 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Replying to the thread, not just the email since I was on vacations.<br>
<br>
First, note that there is a nomenclature issue. A section in ELF/COFF<br>
is closer to an atom in MachO than a MachO section IMHO.<br>
<br>
A rose by any other name would smell as sweet, but sure as hell<br>
creates a lot of confusion :-)<br>
<span class=""><br>
On 4 May 2015 at 18:05, Chris Lattner <<a href="mailto:clattner@apple.com">clattner@apple.com</a>> wrote:<br>
> On May 4, 2015, at 1:16 PM, Joerg Sonnenberger <<a href="mailto:joerg@britannica.bec.de">joerg@britannica.bec.de</a>> wrote:<br>
>> It has been said in this thread before, but I fail to see how the atom<br>
>> model is an actual improvement over the fine grained section model. It<br>
>> seems to be artifically restricted for no good reasons.<br>
><br>
> Sections come with a huge amount of bloat and overhead that atoms do not.<br>
<br>
</span>No, they don't. Not on ELF for sure.<br>
<br>
On ELF a section is just a entry into a table marking a region in the<br>
file. The "huge amount of bloat" that people associate with sections<br>
is actually just the extra space for the ultra large section names<br>
".text._ZFoo....". Create multiple sections with the same name (I<br>
implemented that) and the bloat goes away.<br>
<br>
As has been pointed before, a section in ELF is just a better version<br>
of what is called an Atom in lld: It is a chunk of the file that the<br>
linker can move, but it also supports multiple symbols, which is handy<br>
for things like making the C1 and C2 constructors share the same<br>
address or how MSVC implement vtables+rtti.<br>
<br>
Atoms being a distinct entity from sections (i.e., having non atomic<br>
sections) is a necessity for MachO because it has more restrictive<br>
sections (as Kevin was kind enough to explain).<br>
<br>
Another way of looking at it (for understanding, I wouldn't use the<br>
nomenclature in code) is that with this proposal lld will still be<br>
atom based, we will just be extending atoms to support multiple<br>
symbols. The logic for splitting sections into atoms would become<br>
<br>
* ELF/COFF: one atom per section.<br>
* MachO: One atom per global symbol.<br></blockquote><div><br></div><div>I guess, looking back at Nick's comment:</div><div><br></div><div>"<span style="font-size:12.8000001907349px">The atom model is a good fit for the llvm compiler model for all architectures.  There is a one-to-one mapping between llvm::GlobalObject (e.g. function or global variable) and lld:DefinedAtom."</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">it seems that the primary issue on the ELF/COFF side is that currently the LLVM backends are taking a finer-grained atomicity that is present inside LLVM, and losing information by converting that to a coarser-grained atomicity that is the typical "section" in ELF/COFF.</span></div><div><span style="font-size:12.8000001907349px">But doesn't -ffunction-sections -fdata-sections already fix this, basically?</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">On the Mach-O side, the issue seems to be that Mach-O's notion of section carries more hard-coded meaning than e.g. ELF, so at the very least another layer of subdivision below what Mach-O calls "section" would be needed to preserve this information; currently symbols are used as a bit of a hack as this "sub-section" layer.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">So the problem seems to be that the transport format between the compiler and linker varies by platform, and each one has a different way to represent things, some can't represent everything we want to do, apparently.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">BUT it sounds like at least relocatable ELF semantics can, in principle, represent everything that we can imagine an "atom-based file format"/"native format" to want to represent. </span><span style="font-size:12.8000001907349px">Just to play devil's advocate here, let's start out with the "native format" being relocatable ELF - on *all platforms*. Relocatable object files are just a transport format between compiler and linker, after all; who cares what we use? If the alternative is a completely new format, then bootstrapping from relocatable ELF is strictly less churn/tooling cost.</span></div><div><br></div><div><span style="font-size:12.8000001907349px">People on the "atom side of the fence", what do you think? Is there anything that we cannot achieve by saying "native"="relocatable ELF"?</span><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">-- Sean Silva</span></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
And so MachO ends up with atoms that have only one symbol, but that is<br>
just a special case.<br>
<span class=""><br>
>> This is another item that has been irritating me. While it is a very<br>
>> laudable goal to not depend on linker scripts for the common case, not<br>
>> having the functionality of fine grained output control is certainly a<br>
>> problem. They are crucial for embedded developers and also at least<br>
>> significant for anything near a system kernel.<br>
><br>
> I’m not saying that the linker should eschew fine grained control, I’m saying it should dump linker scripts (and replace them with something better).  Are you going to argue that linker scripts are great, or that they are what we would end up with if we weren’t driven by backwards compatibility goals?<br>
<br>
</span>I agree that this is a distinct issue. Linker scripts are a backward<br>
compatibility pain. Directly using sections for ELF/COFF is *better*<br>
than what is currently being done in lld.<br>
<br>
As for organization, I agree with Rui's suggestion of 2 linkers in<br>
one. One is ELF/COFF and uses sections, one is MachO and uses atoms.<br>
Even with the split there is still enough common code that I don't<br>
think having two repositories would help.<br>
<br>
I don't agree that there is value in keeping the current atom on top<br>
ELF/COFF. It just adds cost to two formats whose sections are already<br>
flexible atoms. It also prevents optimizations like not even reading<br>
duplicated comdats.<br>
<br>
Last but not least, on the idea of a new object format:<br>
<br>
Everyone that has worked on linkers or assemblers has a list of things<br>
they don't like about the format that was being used (I do for sure).<br>
It is entirely possible that if we get our thoughts together we can<br>
build a better format.<br>
<br>
Having said that, an object file format has a tremendous cost. Just<br>
look at the pain that is maintaining support for mips' interpretation<br>
of r_info. We have to be sure there is a genuine advantage to it<br>
before adding a new object format to the world. To know that I think<br>
we need to push the current formats to see how far they go.<br>
<br>
As an analogy, imagine if people working on BFD had decided that ELF<br>
linking was too slow or missing features and had decided to create a<br>
new format that fit BFD better. That would have been really<br>
unfortunate, because as gold showed the problem was not ELF, it was<br>
the organization of BFD, but now we would probably be stuck supporting<br>
4 formats in llvm and lld.<br>
<br>
Once we have a linker (and MC) that is as good as it gets for ELF/COFF<br>
and MachO we well be in a good position for discussing a new format.<br>
<br>
Cheers,<br>
Rafael<br>
<div class=""><div class="h5"><br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></div><br></div></div>