On Mon, Jan 8, 2018 at 3:22 AM, Peter Smith <peter.smith at linaro.org> wrote:> On 8 January 2018 at 09:32, James Henderson via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > On 8 January 2018 at 08:14, Rui Ueyama <ruiu at google.com> wrote: > >> > >> On Mon, Jan 8, 2018 at 3:55 AM, Sean Silva via llvm-dev > >> <llvm-dev at lists.llvm.org> wrote: > >>> > >>> > >>> > >>> On Jan 7, 2018 5:02 PM, "Cary Coutant via llvm-dev" > >>> <llvm-dev at lists.llvm.org> wrote: > >>> > >>> > I think we all agree that blindly allowing the linker to honor the > >>> > options > >>> > would be scary. I agree that we should whitelist the options, and am > >>> > of the > >>> > opinion that we should force validation on the linker side (use of > any > >>> > option which the linker doesn't support in this form can be fatal). > >>> > Starting small is the best way, with `-l` and `-L` as a starting > point. > >>> > I > >>> > want to retain the ability to add additional options which may not be > >>> > available in all linkers. However, whitelisting obviously requires > >>> > working > >>> > with the linker as would adding such options, so that could be > handled > >>> > at > >>> > that time. > >>> > >>> This is actually why I'd prefer a new "language" over just > >>> whitelisting options. With "lib", "file", and "path", as I suggested, > >>> there's no question whether an option like "-no-pie" is supported, and > >>> no temptation to even try. > >>> > >>> > >>> That's a very simple and elegant solution. > >> > >> > >> I really like that approach too. Command line options and "embedded > >> options" are different, so making them actually look different makes > sense. > > > > > > +1 from me. This is very similar to what we have in the Playstation > linker > > (which uses integers instead of strings to denote the type of > directive). As > > Paul mentioned earlier, we support "lib" and "export" directives, both of > > which would fit nicely into this format. > > > >> > > I'm wondering how much of the likely extensions are already covered by > linker script commands > (https://sourceware.org/binutils/docs/ld/File-Commands.html#File-Commands > ). > Would it be worth investigating embedding fragments of linker script > [*] in the same way as the .directive sections that could be > concatenated or overridden by any user provided linker script? This > would have some advantages: > - there is already a specification and implementation of the commands > and experience of their use and limitations. > - it will be easier to resolve conflicts with existing linker script > commands that might conflict. > - if new commands are needed they can be added to linker scripts. >If we allow users embed linker scripts to object files, all ELF linkers will have to start supporting the linker script even for linking trivial programs. I don't think that's a good situation. IMO linker script is too powerful and too GNU-ish that we want to use it only for some limited purposes (e.g. embedded programming.) [*] The encoding in the object file need not match, as long as the> permitted set of options can map 1:1 to a linker script command. > > My experience with Arm Build Attributes, which are used to reason > about compatibility of relocatable objects and not communication of > options; is that users expect to be able to move binary only objects > between projects, and information embedded in object files that isn't > easily accessible to them that causes a link to fail is extremely > unpopular. I'm definitely of the opinion that we should be cautious > with what we allow to be put in. > > Peter >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180108/eb823343/attachment.html>
I was thinking specifically of the subset of the commands for dealing with files, for example INPUT, GROUP and SEARCH_DIR. I agree that it would not be wise to allow the full generality of linker scripts. Thinking about this a bit more I think my main concern is that we should try hard to make sure that any commands that are embedded in an object file are compatible with any equivalent linker script commands. On 8 January 2018 at 17:35, Rui Ueyama <ruiu at google.com> wrote:> On Mon, Jan 8, 2018 at 3:22 AM, Peter Smith <peter.smith at linaro.org> wrote: >> >> On 8 January 2018 at 09:32, James Henderson via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >> > On 8 January 2018 at 08:14, Rui Ueyama <ruiu at google.com> wrote: >> >> >> >> On Mon, Jan 8, 2018 at 3:55 AM, Sean Silva via llvm-dev >> >> <llvm-dev at lists.llvm.org> wrote: >> >>> >> >>> >> >>> >> >>> On Jan 7, 2018 5:02 PM, "Cary Coutant via llvm-dev" >> >>> <llvm-dev at lists.llvm.org> wrote: >> >>> >> >>> > I think we all agree that blindly allowing the linker to honor the >> >>> > options >> >>> > would be scary. I agree that we should whitelist the options, and >> >>> > am >> >>> > of the >> >>> > opinion that we should force validation on the linker side (use of >> >>> > any >> >>> > option which the linker doesn't support in this form can be fatal). >> >>> > Starting small is the best way, with `-l` and `-L` as a starting >> >>> > point. >> >>> > I >> >>> > want to retain the ability to add additional options which may not >> >>> > be >> >>> > available in all linkers. However, whitelisting obviously requires >> >>> > working >> >>> > with the linker as would adding such options, so that could be >> >>> > handled >> >>> > at >> >>> > that time. >> >>> >> >>> This is actually why I'd prefer a new "language" over just >> >>> whitelisting options. With "lib", "file", and "path", as I suggested, >> >>> there's no question whether an option like "-no-pie" is supported, and >> >>> no temptation to even try. >> >>> >> >>> >> >>> That's a very simple and elegant solution. >> >> >> >> >> >> I really like that approach too. Command line options and "embedded >> >> options" are different, so making them actually look different makes >> >> sense. >> > >> > >> > +1 from me. This is very similar to what we have in the Playstation >> > linker >> > (which uses integers instead of strings to denote the type of >> > directive). As >> > Paul mentioned earlier, we support "lib" and "export" directives, both >> > of >> > which would fit nicely into this format. >> > >> >> >> >> I'm wondering how much of the likely extensions are already covered by >> linker script commands >> >> (https://sourceware.org/binutils/docs/ld/File-Commands.html#File-Commands). >> Would it be worth investigating embedding fragments of linker script >> [*] in the same way as the .directive sections that could be >> concatenated or overridden by any user provided linker script? This >> would have some advantages: >> - there is already a specification and implementation of the commands >> and experience of their use and limitations. >> - it will be easier to resolve conflicts with existing linker script >> commands that might conflict. >> - if new commands are needed they can be added to linker scripts. > > > If we allow users embed linker scripts to object files, all ELF linkers will > have to start supporting the linker script even for linking trivial > programs. I don't think that's a good situation. IMO linker script is too > powerful and too GNU-ish that we want to use it only for some limited > purposes (e.g. embedded programming.) > >> [*] The encoding in the object file need not match, as long as the >> permitted set of options can map 1:1 to a linker script command. >> >> My experience with Arm Build Attributes, which are used to reason >> about compatibility of relocatable objects and not communication of >> options; is that users expect to be able to move binary only objects >> between projects, and information embedded in object files that isn't >> easily accessible to them that causes a link to fail is extremely >> unpopular. I'm definitely of the opinion that we should be cautious >> with what we allow to be put in. >> >> Peter > >
On Mon, Jan 8, 2018 at 9:51 AM, Peter Smith via llvm-dev < llvm-dev at lists.llvm.org> wrote:> I was thinking specifically of the subset of the commands for dealing > with files, for example INPUT, GROUP and SEARCH_DIR. I agree that it > would not be wise to allow the full generality of linker scripts. > Thinking about this a bit more I think my main concern is that we > should try hard to make sure that any commands that are embedded in an > object file are compatible with any equivalent linker script commands. >I'm not sure that "compatible with any equivalent linker script commands" is a goal that we want to achieve. That might in principle simplify the spec, but I think that in practice the difficulties specifying what the "embedded linker options" mean will be about how the object's position in the command line interacts with the semantics (e.g. does it go at the end, or right after the current object file, or unspecified). I don't think that tying ourselves to linker scripts really simplifies this at all. -- Sean Silva> > On 8 January 2018 at 17:35, Rui Ueyama <ruiu at google.com> wrote: > > On Mon, Jan 8, 2018 at 3:22 AM, Peter Smith <peter.smith at linaro.org> > wrote: > >> > >> On 8 January 2018 at 09:32, James Henderson via llvm-dev > >> <llvm-dev at lists.llvm.org> wrote: > >> > On 8 January 2018 at 08:14, Rui Ueyama <ruiu at google.com> wrote: > >> >> > >> >> On Mon, Jan 8, 2018 at 3:55 AM, Sean Silva via llvm-dev > >> >> <llvm-dev at lists.llvm.org> wrote: > >> >>> > >> >>> > >> >>> > >> >>> On Jan 7, 2018 5:02 PM, "Cary Coutant via llvm-dev" > >> >>> <llvm-dev at lists.llvm.org> wrote: > >> >>> > >> >>> > I think we all agree that blindly allowing the linker to honor the > >> >>> > options > >> >>> > would be scary. I agree that we should whitelist the options, and > >> >>> > am > >> >>> > of the > >> >>> > opinion that we should force validation on the linker side (use of > >> >>> > any > >> >>> > option which the linker doesn't support in this form can be > fatal). > >> >>> > Starting small is the best way, with `-l` and `-L` as a starting > >> >>> > point. > >> >>> > I > >> >>> > want to retain the ability to add additional options which may not > >> >>> > be > >> >>> > available in all linkers. However, whitelisting obviously > requires > >> >>> > working > >> >>> > with the linker as would adding such options, so that could be > >> >>> > handled > >> >>> > at > >> >>> > that time. > >> >>> > >> >>> This is actually why I'd prefer a new "language" over just > >> >>> whitelisting options. With "lib", "file", and "path", as I > suggested, > >> >>> there's no question whether an option like "-no-pie" is supported, > and > >> >>> no temptation to even try. > >> >>> > >> >>> > >> >>> That's a very simple and elegant solution. > >> >> > >> >> > >> >> I really like that approach too. Command line options and "embedded > >> >> options" are different, so making them actually look different makes > >> >> sense. > >> > > >> > > >> > +1 from me. This is very similar to what we have in the Playstation > >> > linker > >> > (which uses integers instead of strings to denote the type of > >> > directive). As > >> > Paul mentioned earlier, we support "lib" and "export" directives, both > >> > of > >> > which would fit nicely into this format. > >> > > >> >> > >> > >> I'm wondering how much of the likely extensions are already covered by > >> linker script commands > >> > >> (https://sourceware.org/binutils/docs/ld/File- > Commands.html#File-Commands). > >> Would it be worth investigating embedding fragments of linker script > >> [*] in the same way as the .directive sections that could be > >> concatenated or overridden by any user provided linker script? This > >> would have some advantages: > >> - there is already a specification and implementation of the commands > >> and experience of their use and limitations. > >> - it will be easier to resolve conflicts with existing linker script > >> commands that might conflict. > >> - if new commands are needed they can be added to linker scripts. > > > > > > If we allow users embed linker scripts to object files, all ELF linkers > will > > have to start supporting the linker script even for linking trivial > > programs. I don't think that's a good situation. IMO linker script is too > > powerful and too GNU-ish that we want to use it only for some limited > > purposes (e.g. embedded programming.) > > > >> [*] The encoding in the object file need not match, as long as the > >> permitted set of options can map 1:1 to a linker script command. > >> > >> My experience with Arm Build Attributes, which are used to reason > >> about compatibility of relocatable objects and not communication of > >> options; is that users expect to be able to move binary only objects > >> between projects, and information embedded in object files that isn't > >> easily accessible to them that causes a link to fail is extremely > >> unpopular. I'm definitely of the opinion that we should be cautious > >> with what we allow to be put in. > >> > >> Peter > > > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180108/02fc29c0/attachment-0001.html>