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