similar to: Compatibility issue with go

Rui Ueyama <ruiu at google.com> writes: > On Tue, Dec 5, 2017 at 1:22 PM, Rafael Avila de Espindola < > rafael.espindola at gmail.com> wrote: > >> Martin Richtarsky <s at martinien.de> writes: >> >> > Output looks as follows [1] Seems sh_offset is missing? >> >> That is what readelf prints as Off >> >> > [17] .rela.text

But that would disable mmap IO on systems that don't support fallocate. I'm not sure if OpenBSD people are for example happy about that. On Mon, Oct 30, 2017 at 2:03 PM, Rafael Avila de Espindola < rafael.espindola at gmail.com> wrote: > Rui Ueyama via llvm-dev <llvm-dev at lists.llvm.org> writes: > > > If your system does not support fallocate(2), we use

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:

On Fri, Jan 27, 2017 at 1:31 PM, Rui Ueyama <ruiu at google.com> wrote: > Sean, > > So as you noticed that linker script tokenization rule is not very trivial > -- it is context sensitive. The current lexer is extremely simple and > almost always works well. Improving "almost always" to "perfect" is not > high priority because we have many more high

Martin Richtarsky <s at martinien.de> writes: > Output looks as follows [1] Seems sh_offset is missing? That is what readelf prints as Off > [17] .rela.text RELA 0000000000000000 071423 001728 18 > 1 4 8 The offset of rela text should have been aligned, but it is not. Can you report a bug on icc? As a work around using the gnu assembler if possible

I got curious how the lld produced gnu hash tables compared to gold. To test that I timed "perf record ninja check-llvm" (just the lit run) in a BUILD_SHARED_LIBS build. The performance was almost identical, so I decided to try sysv versus gnu (both produced by lld). The results are interesting: % grep -v '^#' perf-gnu/perf.report-by-dso-sym | head 38.77% ld-2.24.so

----- 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>, "Andrew Kelley" > <superjoe30 at gmail.com> > Sent: Tuesday, December 13, 2016

On Tue, Dec 13, 2016 at 12:40 PM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > From: "Rafael Avila de Espindola via llvm-dev" <llvm-dev at lists.llvm.org> > > To: "Andrew Kelley" <superjoe30 at gmail.com>, "Rui Ueyama" < > ruiu at google.com> > > Cc: "llvm-dev" <llvm-dev at

> Hmm..., the crux of not being able to lex arithmetic expressions seems to > be due to lack of context sensitivity. E.g. consider `foo*bar`. Could be a > multiplication, or could be a glob pattern. > > Looking at the code more closely, adding context sensitivity wouldn't be > that hard. In fact, our ScriptParserBase class is actually a lexer (look at > the interface; it

Andrew Kelley via llvm-dev <llvm-dev at lists.llvm.org> writes: > On Tue, Dec 13, 2016 at 1:06 PM, Rui Ueyama via llvm-dev < > llvm-dev at lists.llvm.org> wrote: >> >> That said, I think the current our "API" to allow users call our linker's >> main function hit the sweet spot. I know at least a few LLVM-based language >> developers who want

Thanks Rafael, wondering as of what is the level of support for ARM and is it close to production quality? Thanks On Mon, Feb 26, 2018 at 2:06 PM, Rafael Avila de Espindola < rafael.espindola at gmail.com> wrote: > Not sure there is an official POC, you are probably better off asking > whatever question you have directly on the list. > > Cheers, > Rafael > > Sumonto

On Wed, Nov 8, 2017 at 9:33 AM, Rafael Avila de Espindola < rafael.espindola at gmail.com> wrote: > Rui Ueyama <ruiu at google.com> writes: > > >> If you are creating an executable and if your executable is not > >> > position-independent, you're using Initial Exec model by default > which is > >> > as fast as variables accessed through

I think ARM ELF is pretty good. I was able to link clang with it some time ago and it now has support for thunks. Cheers, Rafael Sumonto Ghosh <sumonto.ghosh at gmail.com> writes: > Thanks Rafael, wondering as of what is the level of support for ARM and is > it close to production quality? > > Thanks > > On Mon, Feb 26, 2018 at 2:06 PM, Rafael Avila de Espindola <

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: >>> This will also greatly facilitate certain measurements I'd like to do >>> w.r.t. different strategies for avoiding

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

Hello, I am trying to bootstrap on ARM linux EABI using a qemu chroot to better test my changes on at least one more architecture. I am using the following configure line: ../gcc/configure --prefix=/home/espindola/install/ --program-prefix=llvm- --enable-languages=c --disable-shared --disable-multilib --enable-llvm=/home/espindola/build --enable-checking arm-linux-gnueabi The bootstrap fails

For some time now the gold linker has support for plugins and llvm has a plugin for it. Unfortunately, it was still not possible to do fully transparent LTO on linux because ar had no support for plugins and a library created with llvm files in it would have no symbol table and would be rejected by gold. Today support for plugins has been committed to BFD. That is the file format abstraction

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

>> In my opinion having a general linker in the JIT is sub optimal. We >> should not be desiginig lld around an idea there is not even a >> consensus > > I think there is consensus on not wanting duplicate functionality > between LLD and lib/ExecutionEngine. That does not mean that the JIT > needs a general linker, but that whatever functionality is common is >

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