similar to: RFC: ELF Autolinking

On Thu, Mar 14, 2019 at 3:32 PM Peter Smith <peter.smith at linaro.org> wrote: > Hello, > > I've put some comments on the proposal inline. Having to had to debug > library selection problems where all the libraries are visible on the > linker command line, I would prefer if people didn't embed difficult > to find directives in object files, but I'm guessing in

On Thu, Mar 14, 2019 at 6:27 PM Peter Collingbourne <peter at pcc.me.uk> wrote: > > > On Thu, Mar 14, 2019 at 6:08 AM bd1976 llvm via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> At Sony we offer autolinking as a feature in our ELF toolchain. We would >> like to see full support for this feature upstream as there is anecdotal >> evidence that

On Thu, Mar 14, 2019 at 9:28 AM Reid Kleckner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > I guess I agree it would be best to remove the objfile linker option > support and replace it with just auto-linking. We already have a mechanism > for adding new features to object files: .note sections. Linkers already > know to ignore ones that they don't

On Mon, Mar 18, 2019 at 8:02 PM Rui Ueyama <ruiu at google.com> wrote: > On Thu, Mar 14, 2019 at 1:05 PM bd1976 llvm via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> On Thu, Mar 14, 2019 at 6:27 PM Peter Collingbourne <peter at pcc.me.uk> >> wrote: >> >>> >>> >>> On Thu, Mar 14, 2019 at 6:08 AM bd1976 llvm via

On Thu, Mar 21, 2019 at 12:06 AM Rui Ueyama <ruiu at google.com> wrote: > Perhaps there's no one clean way to solve this issue, because previously > all libraries and object files are explicitly given to the linker via a > command line and the order of files in the command line matters. That > assumes human intervention to work correctly. Now, the autolinking feature >

Are you planning to add support for "-F" and "-framework" to ELF linkers? On Mon, Mar 25, 2019 at 12:51 AM Saleem Abdulrasool via llvm-dev < llvm-dev at lists.llvm.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 >

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 Thu, Mar 14, 2019 at 5:58 PM Rui Ueyama <ruiu at google.com> wrote: > On Thu, Mar 14, 2019 at 9:45 AM bd1976 llvm via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> On Thu, Mar 14, 2019 at 3:32 PM Peter Smith <peter.smith at linaro.org> >> wrote: >> >>> Hello, >>> >>> I've put some comments on the proposal

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

On Fri, Mar 15, 2019 at 6:23 AM bd1976 llvm <bd1976llvm at gmail.com> wrote: > > > On Thu, Mar 14, 2019 at 6:43 PM bd1976 llvm <bd1976llvm at gmail.com> wrote: > >> >> >> On Thu, Mar 14, 2019 at 5:58 PM Rui Ueyama <ruiu at google.com> wrote: >> >>> On Thu, Mar 14, 2019 at 9:45 AM bd1976 llvm via llvm-dev < >>> llvm-dev at

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 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

Saleem 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

On May 28, 2015, at 5:42 PM, Sean Silva <chisophugis at gmail.com> wrote: > I guess, looking back at Nick's comment: > > "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." > > it seems that the primary issue on the

Not all users compile their code with -ffunction-sections and -fdata-sections. This is to handle usecases when libraries use a mix of object files too. On 7/25/2013 4:10 PM, Rui Ueyama wrote: > Is there any reason -ffunction-sections and -fdata-sections wouldn't work? > If it'll work, it may be be better to say "if you want to get a better > linker output use these

Replying to the thread, not just the email since I was on vacations. First, note that there is a nomenclature issue. A section in ELF/COFF is closer to an atom in MachO than a MachO section IMHO. A rose by any other name would smell as sweet, but sure as hell creates a lot of confusion :-) On 4 May 2015 at 18:05, Chris Lattner <clattner at apple.com> wrote: > On May 4, 2015, at 1:16

On Thu, May 28, 2015 at 6:25 PM, Nick Kledzik <kledzik at apple.com> wrote: > > On May 28, 2015, at 5:42 PM, Sean Silva <chisophugis at gmail.com> wrote: > > I guess, looking back at Nick's comment: > > "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.

> Given how ELF works I would expect an unknown section to simply end up > in the output, but we can use SHF_EXCLUDE to avoid that. Yes, gold currently treats unknown section types pretty much the same as PROGBITS sections. The SHF_ALLOCATE and SHF_EXCLUDE flags would control where and whether the section goes into the output file. Another thing that we need to work out is the link order.

Couldn’t you write the relocations to the ELF executable? I don’t know if current linkers have support for this, but it seems possible in theory to make a relinkable executable. If you want to do this with an already linked executable though, then yea this won’t be possible. On Fri, Jul 20, 2018 at 10:30 AM Reid Kleckner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Typically

I want to make it clear that I didn't (at least intend to) compromise flexibility or beauty of design with short-term performance gain. I was trying to do simple things in a simple way for both humans and computers, and I believe I did that fairly well. I'd even argue that the new design is cleaner and more expressive than before, because the "atom" model is in some part too