similar to: Linker Option support for ELF

On Wed, Jan 3, 2018 at 4:02 PM, Saleem Abdulrasool <compnerd at compnerd.org> wrote: > Hello all, > > There was some interest from a number of a few people about adding support > for embedded linker options to ELF. This would be an extension that > requires linker support to actually work, but has significant prior art > with PE/COFF as well as MachO both having support

On Wed, Jan 3, 2018 at 8:08 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > On Wed, Jan 3, 2018 at 4:02 PM, Saleem Abdulrasool <compnerd at compnerd.org> > wrote: > >> Hello all, >> >> There was some interest from a number of a few people about adding >> support for embedded linker options to ELF. This would be an extension >> that

Saleem Abdulrasool via llvm-dev <llvm-dev at lists.llvm.org> writes: > Hello all, > > There was some interest from a number of a few people about adding support > for embedded linker options to ELF. This would be an extension that > requires linker support to actually work, but has significant prior art > with PE/COFF as well as MachO both having support for this. >

We should do this. ELF is the odd duck out that lacks this capability. I agree with Rafael we should have a whitelist of flags that we support, but I'd rather leave the syntax as more or less just a response file. That's basically what's implemented for COFF. Sent from phone On Wed, Jan 3, 2018, 4:13 PM Rafael Avila de Espindola via llvm-dev < llvm-dev at lists.llvm.org>

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 is a scenario in which the feature is useful: when you include math.h, a compiler (which is driven by some pragma)

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

On Sat, Jan 6, 2018 at 8:56 AM, Saleem Abdulrasool <compnerd at compnerd.org> wrote: > > 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

> On Jan 6, 2018, at 6:55 PM, Rui Ueyama <ruiu at google.com> wrote: > > On Sat, Jan 6, 2018 at 8:56 AM, Saleem Abdulrasool <compnerd at compnerd.org <mailto:compnerd at compnerd.org>> wrote: > > On Fri, Jan 5, 2018 at 2:30 AM Rui Ueyama <ruiu at google.com <mailto:ruiu at google.com>> wrote: > Thank you for starting the discussion thread. >

On Wed, Jan 3, 2018 at 4:13 PM, Rafael Avila de Espindola < rafael.espindola at gmail.com> wrote: > Saleem Abdulrasool via llvm-dev <llvm-dev at lists.llvm.org> writes: > > > Hello all, > > > > There was some interest from a number of a few people about adding > support > > for embedded linker options to ELF. This would be an extension that > >

Saleem Abdulrasool <compnerd at compnerd.org> writes: > So you are suggesting that the backend take the opaque blob, peer through > it, map it to something else and then encode that? The llvm backend? No, it should probably be done by whatever produced the IR. If viewing this a part of the file format, having the FE create a metadata asking for (add_lib_enum_value, "foo.a")

On Wed, Jan 3, 2018 at 8:30 PM, Reid Kleckner <rnk at google.com> wrote: > We should do this. ELF is the odd duck out that lacks this capability. > Exactly, and the amount of work that swift goes through to accommodate this is silly. > I agree with Rafael we should have a whitelist of flags that we support, > but I'd rather leave the syntax as more or less just a response

> 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 Wed, Mar 27, 2019 at 2:03 AM Saleem Abdulrasool <compnerd at compnerd.org> wrote: > On Tue, Mar 26, 2019 at 11:13 AM bd1976 llvm <bd1976llvm at gmail.com> wrote: > >> Thanks Saleem/James. >> >> On Tue, Mar 26, 2019 at 5:15 AM Saleem Abdulrasool <compnerd at compnerd.org> >> wrote: >> >>> Yes, I don't think that supporting all

On Wed, Mar 7, 2018 at 9:56 AM Eric Christopher via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi Zach! > > I've been thinking a bit about this for a while now and I'm still of two > opinions: > > On Wed, Mar 7, 2018 at 9:21 AM Zachary Turner via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Currently llvm-objcopy only supports ELF

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

Thanks Saleem/James. On Tue, Mar 26, 2019 at 5:15 AM Saleem Abdulrasool <compnerd at compnerd.org> wrote: > Yes, I don't think that supporting all options is entirely possible. But, > there is certainly some allure to it, as it is a really powerful feature > (which you can tell from the behaviour of link and `.drectve` section). > The problem with all options is that

Hi, It's not clear to me what you mean by CLI "subcommands". Would you mind giving a brief example? Up to now, we've been trying to keep llvm-objcopy as close as possible to GNU objcopy, to make transitioning between them easier (I'm thinking in particular things like DWO generation). There are a small number of edge cases/unusual behaviours that we have chosen not to

On Sun, Mar 24, 2019 at 9:51 PM Saleem Abdulrasool <compnerd at compnerd.org> wrote: > Sorry for the late chiming in. > > Yes, swift does use autolinking, and I would like to use that on all the > targets. The only target which does not support this functionality > currently are ELF based. That said, I think that `#pragma comment(link, > ...)` is insufficient for my

On Wed, Jun 18, 2014 at 10:25 AM, Saleem Abdulrasool <compnerd at compnerd.org> wrote: > On Wed, Jun 18, 2014 at 9:09 AM, Damanjit Singh <dsingh at adobe.com> wrote: > >> Hi Saleem, >> >> Though a simple app works great I am facing few issues trying to link a >> slightly complex object file, generated via LLVM, with some libs generated >> via

On Thu, Jun 27, 2019 at 2:05 PM Chris Lattner <clattner at nondot.org> wrote: > Saleem, Owen, others on the thread who are concerned about this: it seems > that some of the concern is that the project goals are too narrow, and thus > the eventual result may not serve the full community well over time. > > Would any of you be interested in what we should consider as the list