search for: linker_direct

James Henderson via llvm-dev <llvm-dev at lists.llvm.org> writes: > By my understanding, the proposal is that the user input looks something > like: > > #pragma linker_directive("lib", "m") > > which is passed essentially as is to the linker, i.e. the directive payload > is a pair of strings, the first being "lib", the second "m". It is then up > to the linker to decide if it supports "lib" directives, and tr...

By my understanding, the proposal is that the user input looks something like: #pragma linker_directive("lib", "m") which is passed essentially as is to the linker, i.e. the directive payload is a pair of strings, the first being "lib", the second "m". It is then up to the linker to decide if it supports "lib" directives, and translate that into t...

> On Jan 7, 2018, at 5:02 PM, Cary Coutant <ccoutant at gmail.com> 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

> On Jan 9, 2018, at 2:32 AM, James Henderson <jh7370.2008 at my.bristol.ac.uk> wrote: > > By my understanding, the proposal is that the user input looks something like: > > #pragma linker_directive("lib", "m") > > which is passed essentially as is to the linker, i.e. the directive payload is a pair of strings, the first being "lib", the second "m". It is then up to the linker to decide if it supports "lib" directives, and translate t...

...aleem Abdulrasool via llvm-dev <llvm-dev at lists.llvm.org> writes: >> On Jan 9, 2018, at 2:32 AM, James Henderson <jh7370.2008 at my.bristol.ac.uk> wrote: >> >> By my understanding, the proposal is that the user input looks something like: >> >> #pragma linker_directive("lib", "m") >> >> which is passed essentially as is to the linker, i.e. the directive payload is a pair of strings, the first being "lib", the second "m". It is then up to the linker to decide if it supports "lib" directives, and tra...

...be needed, since the compiler can simply generate an undef symbol for that case. For the section format, I'd suggest a series of null-terminated strings, alternating between tags and values, so that no quote or escape parsing is necessary. For the header files, a simple syntax like #pragma linker_directive "lib" "m" would provide the extensibility needed to add new tags with no additional support in the front end or back end. -cary

...eally is driven more by the LLVM IR (which I suppose is possible to alter): https://llvm.org/docs/LangRef.html#automatic-linker-flags-named-metadata <https://llvm.org/docs/LangRef.html#automatic-linker-flags-named-metadata> > For the header files, a simple syntax like > > #pragma linker_directive "lib" "m" > > would provide the extensibility needed to add new tags with no > additional support in the front end or back end. I *really* wish to avoid this discussion right now. I am happy to loop you into a subsequent thread discussing that. I figure that this...

...y difference is instead of TLV entries, it is simply the raw entry. My resistance to the TLV really is driven more by the LLVM IR (which I suppose is possible to alter): https://llvm.org/docs/LangRef.html#automatic-linker-flags-named-metadata For the header files, a simple syntax like #pragma linker_directive "lib" "m" would provide the extensibility needed to add new tags with no additional support in the front end or back end. I *really* wish to avoid this discussion right now. I am happy to loop you into a subsequent thread discussing that. I figure that this will be a muc...

...LLVM IR (which I suppose is possible to alter): > > https://llvm.org/docs/LangRef.html#automatic-linker-flags-named-metadata <https://llvm.org/docs/LangRef.html#automatic-linker-flags-named-metadata> > >> For the header files, a simple syntax like >> >> #pragma linker_directive "lib" "m" >> >> would provide the extensibility needed to add new tags with no >> additional support in the front end or back end. > > I *really* wish to avoid this discussion right now. I am happy to loop you into a subsequent thread discussing tha...

On Fri, Jan 5, 2018 at 2:30 AM Rui Ueyama <ruiu at google.com> wrote: > Thank you for starting the discussion thread. > > In general I'm in favor of the proposal. Defining a generic way to convey > some information from the compiler to the linker is useful, and it looks > like it is just a historical reason that the ELF lacks the feature at the > moment. > > This