similar to: RFC: ELF Autolinking

Displaying 20 results from an estimated 50000 matches similar to: "RFC: ELF Autolinking"

2019 Mar 14
3
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
2019 Mar 14
2
RFC: ELF Autolinking
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
2019 Mar 14
3
RFC: ELF Autolinking
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
2019 Mar 19
2
RFC: ELF Autolinking
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
2019 Mar 21
3
RFC: ELF Autolinking
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 >
2019 Mar 25
3
RFC: ELF Autolinking
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 >
2019 Mar 25
2
RFC: ELF Autolinking
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
2019 Mar 14
2
RFC: ELF Autolinking
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
2019 Mar 26
2
RFC: ELF Autolinking
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
2019 Mar 18
2
RFC: ELF Autolinking
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
2019 Mar 27
4
RFC: ELF Autolinking
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
2018 Jan 10
3
Linker Option support for ELF
> 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
2018 Jan 10
0
Linker Option support for ELF
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
2015 May 29
8
[LLVMdev] LLD improvement plan
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
2013 Jul 25
2
[LLVMdev] [PROPOSAL] ELF safe/unsafe sections
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
2015 May 28
2
[LLVMdev] LLD improvement plan
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
2015 May 29
0
[LLVMdev] LLD improvement plan
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.
2018 Jan 13
2
Linker Option support for ELF
> 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.
2018 Jul 23
2
Relinking (syscall-free) ELF executable into Mach-O and PE executables
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
2015 May 29
3
[LLVMdev] LLD improvement plan
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