similar to: LLD: Calling from within LLVM

> On Dec 13, 2016, at 10:06 AM, Rui Ueyama <ruiu at google.com> wrote: > > On Tue, Dec 13, 2016 at 9:28 AM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: > > > On Dec 13, 2016, at 5:55 AM, Rafael Avila de Espindola via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > >

----- Original Message ----- > From: "Rafael Avila de Espindola via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Mehdi Amini" <mehdi.amini at apple.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Tuesday, December 13, 2016 12:10:08 PM > Subject: Re: [llvm-dev] LLD status update and performance chart > > Mehdi Amini

Initial issue is related to R_MIPS_GPREL16/32 relocations. When we calculate such relocations we need to know _gp symbol's value. This value might come from different sources. Usually we setup it using constant offset from the .got section. Also it might be defined by a linker script. And in rare but possible case it comes from .reginfo / .MIPS.options sections. Got example, GNU bfd linker

On Tue, Dec 13, 2016 at 10:37 AM, Hal Finkel via llvm-dev < llvm-dev at lists.llvm.org> wrote: > ----- Original Message ----- > > From: "Rafael Avila de Espindola via llvm-dev" <llvm-dev at lists.llvm.org> > > To: "Mehdi Amini" <mehdi.amini at apple.com> > > Cc: "llvm-dev" <llvm-dev at lists.llvm.org> > > Sent:

You are right. LLD does not have this problem. Initially I bumped into the MIPS specific bug related to GP relative relocations calculation. I tried to make reproduction script as general as possible and mistakenly make it too general. So now with your help I realized that the problem solely affects MIPS. On Tue, Sep 27, 2016 at 8:46 PM, Peter Smith <peter.smith at linaro.org> wrote: >

Hi, I've tracked down what I believe is a bug in lld's relocation processing for R_X86_64_PC32 REL relocations. I'm producing the object file in a slightly unusual way: I'm using objcopy on a relocatable i386 ELF object file to convert it to x86_64 which transforms a R_386_PC32 into a R_X86_64_PC32. Steps to reproduce: 1. Assemble the attached bug.asm using nasm and note the

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

Hi, Now in case of relocatable object generation LLD merges and copies REL/RELA sections as is and does not touch any addends. But it is incorrect. If we have a relocation which targets a section, we have to adjust the relocation's addend to take in account that the section might be merged with other ones. Here is the reproduction script: % cat t1.s .data .long 0 .text bar: movl $1,

On Tue, Dec 13, 2016 at 11:02 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Dec 13, 2016, at 10:06 AM, Rui Ueyama <ruiu at google.com> wrote: > > On Tue, Dec 13, 2016 at 9:28 AM, Mehdi Amini <mehdi.amini at apple.com> > wrote: > >> >> > On Dec 13, 2016, at 5:55 AM, Rafael Avila de Espindola via llvm-dev < >> llvm-dev at

As I've mentioned before[1] I've been regularly attempting to build the FreeBSD/amd64 base system with lld, in order to keep track of progress and identify issues on an ongoing basis. As of last November a 'buildword' (i.e., userland build) ran to completion, with several workarounds applied to the FreeBSD base system. However, the result did not actually work. I'm pleased to

> On Dec 13, 2016, at 9:40 AM, Rafael Avila de Espindola <rafael.espindola at gmail.com> wrote: > > Mehdi Amini <mehdi.amini at apple.com> writes: > >>> On Dec 13, 2016, at 5:55 AM, Rafael Avila de Espindola via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> >>> Sean Silva via llvm-dev <llvm-dev at lists.llvm.org> writes:

On 16 December 2016 at 19:28, Rui Ueyama <ruiu at google.com> wrote: > It may be good to compile a wishlist about a linker to collect feature ideas > people wish to use. I honestly know only one major request: embedding a > linker to a program. I guess that this single feature satisfies a majority > of needs as per 80:20 rule, but I really want to know what people wish to >

On Tue, Dec 13, 2016 at 11:02 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Dec 13, 2016, at 10:06 AM, Rui Ueyama <ruiu at google.com> wrote: > > On Tue, Dec 13, 2016 at 9:28 AM, Mehdi Amini <mehdi.amini at apple.com> > wrote: > >> >> > On Dec 13, 2016, at 5:55 AM, Rafael Avila de Espindola via llvm-dev < >> llvm-dev at

> On Dec 13, 2016, at 11:08 AM, Rui Ueyama <ruiu at google.com> wrote: > > On Tue, Dec 13, 2016 at 11:02 AM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: > >> On Dec 13, 2016, at 10:06 AM, Rui Ueyama <ruiu at google.com <mailto:ruiu at google.com>> wrote: >> >> On Tue, Dec 13, 2016 at 9:28 AM, Mehdi

On Wed, May 27, 2015 at 9:06 PM, Rafael Espíndola < rafael.espindola at gmail.com> wrote: > 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

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

The direct cause of this issue is that, previously lld converted common symbols to defined symbols before passing input files to LTO, and after r360841 they are passed as common symbols to LTO. Making lld to work as before is easy, as we can convert common symbols to defined symbols as before. Here is a patch to do that, and I confirmed that that restores the original behavior for the reported

On 4/4/2014 3:46 AM, David Chisnall wrote: > On 3 Apr 2014, at 20:49, Shankar Easwaran <shankare at codeaurora.org> wrote: > >> b) I am not planning to write a demangler. I was planning on using abi::__cxx_demangle if there was one available and the first character in the symbol was a _. >> If MSVC was defined, we would use the Undecorate API. > The demangler that

Hal Finkel <hfinkel at anl.gov> writes: > >> Please tell me what you think about how reusable components would be >> like. Which parts of the linker can be reusable components? Is that >> really feasible? > As far as I'm concerned, your response, "That said, I think the current our 'API' to allow users call our linker's main function hit the sweet

----- Original Message ----- > From: "Rui Ueyama" <ruiu at google.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Rafael Avila de Espindola" <rafael.espindola at gmail.com>, > "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Tuesday, December 13, 2016 12:56:41 PM > Subject: Re: [llvm-dev] LLD status update and