Nobody in this long thread appears to have yet explained why it's a bad idea to allow atomic fragments of code/data (whatever you want to call them: atoms, sections, who cares) to have more than one global symbol attached to them in LLD's internal representation. That seems like it'd provide the flexibility needed for ELF without hurting MachO. If that change'd allow you to avoid splitting the linker into two-codebases-in-one, isn't that preferable? On Thu, May 7, 2015 at 9:38 AM, Joerg Sonnenberger <joerg at britannica.bec.de> wrote:> On Wed, May 06, 2015 at 09:28:54PM -0500, Shankar Easwaran wrote: > > The atom model allowed lld to have a single intermediate > > representation for all the formats ELF/COFF/Mach-O. The native model > > allowed the intermediate representation to be serialized to disk > > too. If the intermediate representations data structures are made > > available to scripting languages most of all linker script script > > layout can be implemented by the end user. A new language also can > > be developed as most of the users need it and it can work on this > > intermediate representation. > > > > The atom model also simplified a lot of usecases like garbage > > collection and having the resolve to deal just with atoms. The > > section model would sound simple from the outside but it it has its > > own challenges like separating the symbol information from section > > information. > > I'm sorry, but I don't get why any of this requires an atom based > representation. Saying that a single intermediate representation for > ELF/COFF on one hand and Mach-O on the other is ironic given the already > mentioned hacks on various layers. Garbage collection doesn't become > more expensive when attaching more than one symbol to each code/data > fragment. Symbol resolution doesn't change when attaching more than one > symbol to each code/data fragment. The list goes on. The single natural > advantage is that you can use a single pointer to the canonical symbol > from a code/data fragment and don't have to use a list/array. Given the > necessary and expensive hacks for splitting sections into (pseudo) > atoms, that doesn't feel like a win. So once again, what actual > advantages for ELF or COFF have been created by the atom model? Mach-O > hardly counts as it doesn't allow the flexibility of the section model > as has been discussed before. > > Joerg > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150511/f1687fb5/attachment.html>
On Mon, May 11, 2015 at 10:56 AM, James Y Knight <jyknight at google.com> wrote:> Nobody in this long thread appears to have yet explained why it's a bad > idea to allow atomic fragments of code/data (whatever you want to call > them: atoms, sections, who cares) to have more than one global symbol > attached to them in LLD's internal representation. > > That seems like it'd provide the flexibility needed for ELF without > hurting MachO. If that change'd allow you to avoid splitting the linker > into two-codebases-in-one, isn't that preferable? >+1 I'd be curious to understand this too.> > > On Thu, May 7, 2015 at 9:38 AM, Joerg Sonnenberger < > joerg at britannica.bec.de> wrote: > >> On Wed, May 06, 2015 at 09:28:54PM -0500, Shankar Easwaran wrote: >> > The atom model allowed lld to have a single intermediate >> > representation for all the formats ELF/COFF/Mach-O. The native model >> > allowed the intermediate representation to be serialized to disk >> > too. If the intermediate representations data structures are made >> > available to scripting languages most of all linker script script >> > layout can be implemented by the end user. A new language also can >> > be developed as most of the users need it and it can work on this >> > intermediate representation. >> > >> > The atom model also simplified a lot of usecases like garbage >> > collection and having the resolve to deal just with atoms. The >> > section model would sound simple from the outside but it it has its >> > own challenges like separating the symbol information from section >> > information. >> >> I'm sorry, but I don't get why any of this requires an atom based >> representation. Saying that a single intermediate representation for >> ELF/COFF on one hand and Mach-O on the other is ironic given the already >> mentioned hacks on various layers. Garbage collection doesn't become >> more expensive when attaching more than one symbol to each code/data >> fragment. Symbol resolution doesn't change when attaching more than one >> symbol to each code/data fragment. The list goes on. The single natural >> advantage is that you can use a single pointer to the canonical symbol >> from a code/data fragment and don't have to use a list/array. Given the >> necessary and expensive hacks for splitting sections into (pseudo) >> atoms, that doesn't feel like a win. So once again, what actual >> advantages for ELF or COFF have been created by the atom model? Mach-O >> hardly counts as it doesn't allow the flexibility of the section model >> as has been discussed before. >> >> Joerg >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150511/f767b933/attachment.html>
If you attach two ore more symbols along with offsets to a chunk of data, it would be a pretty similar to a section. That means that if you want to do something on the atom model, now you have to treat the atoms like sections. I looks like a bad mix of the two. On Mon, May 11, 2015 at 10:56 AM, James Y Knight <jyknight at google.com> wrote:> Nobody in this long thread appears to have yet explained why it's a bad > idea to allow atomic fragments of code/data (whatever you want to call > them: atoms, sections, who cares) to have more than one global symbol > attached to them in LLD's internal representation. > > That seems like it'd provide the flexibility needed for ELF without > hurting MachO. If that change'd allow you to avoid splitting the linker > into two-codebases-in-one, isn't that preferable? > > > On Thu, May 7, 2015 at 9:38 AM, Joerg Sonnenberger < > joerg at britannica.bec.de> wrote: > >> On Wed, May 06, 2015 at 09:28:54PM -0500, Shankar Easwaran wrote: >> > The atom model allowed lld to have a single intermediate >> > representation for all the formats ELF/COFF/Mach-O. The native model >> > allowed the intermediate representation to be serialized to disk >> > too. If the intermediate representations data structures are made >> > available to scripting languages most of all linker script script >> > layout can be implemented by the end user. A new language also can >> > be developed as most of the users need it and it can work on this >> > intermediate representation. >> > >> > The atom model also simplified a lot of usecases like garbage >> > collection and having the resolve to deal just with atoms. The >> > section model would sound simple from the outside but it it has its >> > own challenges like separating the symbol information from section >> > information. >> >> I'm sorry, but I don't get why any of this requires an atom based >> representation. Saying that a single intermediate representation for >> ELF/COFF on one hand and Mach-O on the other is ironic given the already >> mentioned hacks on various layers. Garbage collection doesn't become >> more expensive when attaching more than one symbol to each code/data >> fragment. Symbol resolution doesn't change when attaching more than one >> symbol to each code/data fragment. The list goes on. The single natural >> advantage is that you can use a single pointer to the canonical symbol >> from a code/data fragment and don't have to use a list/array. Given the >> necessary and expensive hacks for splitting sections into (pseudo) >> atoms, that doesn't feel like a win. So once again, what actual >> advantages for ELF or COFF have been created by the atom model? Mach-O >> hardly counts as it doesn't allow the flexibility of the section model >> as has been discussed before. >> >> Joerg >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150511/0b54b2de/attachment.html>
On Mon, May 11, 2015 at 11:13 AM, Rui Ueyama <ruiu at google.com> wrote:> If you attach two ore more symbols along with offsets to a chunk of data, > it would be a pretty similar to a section. That means that if you want to > do something on the atom model, now you have to treat the atoms like > sections. >What do you lose/pay by having to treat the atoms like sections?> I looks like a bad mix of the two. > > On Mon, May 11, 2015 at 10:56 AM, James Y Knight <jyknight at google.com> > wrote: > >> Nobody in this long thread appears to have yet explained why it's a bad >> idea to allow atomic fragments of code/data (whatever you want to call >> them: atoms, sections, who cares) to have more than one global symbol >> attached to them in LLD's internal representation. >> >> That seems like it'd provide the flexibility needed for ELF without >> hurting MachO. If that change'd allow you to avoid splitting the linker >> into two-codebases-in-one, isn't that preferable? >> >> >> On Thu, May 7, 2015 at 9:38 AM, Joerg Sonnenberger < >> joerg at britannica.bec.de> wrote: >> >>> On Wed, May 06, 2015 at 09:28:54PM -0500, Shankar Easwaran wrote: >>> > The atom model allowed lld to have a single intermediate >>> > representation for all the formats ELF/COFF/Mach-O. The native model >>> > allowed the intermediate representation to be serialized to disk >>> > too. If the intermediate representations data structures are made >>> > available to scripting languages most of all linker script script >>> > layout can be implemented by the end user. A new language also can >>> > be developed as most of the users need it and it can work on this >>> > intermediate representation. >>> > >>> > The atom model also simplified a lot of usecases like garbage >>> > collection and having the resolve to deal just with atoms. The >>> > section model would sound simple from the outside but it it has its >>> > own challenges like separating the symbol information from section >>> > information. >>> >>> I'm sorry, but I don't get why any of this requires an atom based >>> representation. Saying that a single intermediate representation for >>> ELF/COFF on one hand and Mach-O on the other is ironic given the already >>> mentioned hacks on various layers. Garbage collection doesn't become >>> more expensive when attaching more than one symbol to each code/data >>> fragment. Symbol resolution doesn't change when attaching more than one >>> symbol to each code/data fragment. The list goes on. The single natural >>> advantage is that you can use a single pointer to the canonical symbol >>> from a code/data fragment and don't have to use a list/array. Given the >>> necessary and expensive hacks for splitting sections into (pseudo) >>> atoms, that doesn't feel like a win. So once again, what actual >>> advantages for ELF or COFF have been created by the atom model? Mach-O >>> hardly counts as it doesn't allow the flexibility of the section model >>> as has been discussed before. >>> >>> Joerg >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150511/0208f4a2/attachment.html>