similar to: lld symbol choice for symbol present in both a shared and a static library, with and without LTO

> -----Original Message----- > From: Peter Smith <peter.smith at linaro.org> > Sent: Monday, June 17, 2019 3:33 AM > To: Eli Friedman <efriedma at qualcomm.com> > Cc: llvm-dev <llvm-dev at lists.llvm.org> > Subject: [EXT] Re: [llvm-dev] lld symbol choice for symbol present in both a > shared and a static library, with and without LTO > > On Fri, 14 Jun

Usage of the builtin appears independent of LTO, see below. With any of -fno-builtin, -fno-builtin-memcpy, and -ffreestanding, which are all typically used to prevent usage of memcpy calls, we still always get a memcpy builtin in TlsDriverEntryPoint(). I see this even without -flto (e.g. try with just -emit-llvm). I guess it is because this memcpy is not coming from the original source, but

Hi Steven, One thing I noticed is that you are defining `memcpy`, which clang has an intrinsic with the same name. Can you try renaming it to a random name, like `foobar`, to see if the problem still exists? On Tue, Jul 16, 2019 at 10:10 AM Shi, Steven <steven.shi at intel.com> wrote: > I’ve submitted a BZ for this issue as below: > > > > Bug 42626 - lld-link crash when

Hi Teresa, Thank you for the help, adding the "used" attribute worked just fine. It made me realize that the memset function is never inlined by the LTO optimization even without my implementation of the "EmitTargetCodeForMemSet" method. I supposed that the passes dealing with the memset function happen too late, is that correct? Thank you again, Romaric On Fri, Aug 28, 2020

Hi Rui, We met a lld-link crash problem when build 32bits openssl1.0 with LTO in uefi firmware. We narrow down and figure out a simple test case to reproduce this problem as blow. Please advise. Thank you! $ cat main.c void TlsDriverEntryPoint () { unsigned char *ret = 0; const unsigned char cryptopro_ext[17] = {0x00,0x00,0x00,0x00,

Yeah, it crashes indeed. I can reproduce the problem locally. Let me see what is going on. On Tue, Jul 16, 2019 at 9:00 PM Shi, Steven <steven.shi at intel.com> wrote: > In my previous test case, after add the `-fno-builtin` to clang then > build, the lld-link still has same crash as below: > > > > $ make > >

lld should not crash in this case (so that's a bug that needs fixing), but setting it aside, did you try adding `-fno-builtin` to clang so that clang doesn't handle `memcpy` as a built-in function? On Tue, Jul 16, 2019 at 8:46 PM Shi, Steven <steven.shi at intel.com> wrote: > Hi Rui, > > For the test case in my previous email, if I change the `memcpy` to > `foobar` in

Thanks for the info Teresa, Regards M Suresh From: Teresa Johnson <tejohnson at google.com> Sent: Thursday, June 20, 2019 7:15 PM To: Mani, Suresh <Suresh.Mani at amd.com> Cc: Rui Ueyama <ruiu at google.com>; llvm-dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] Expected behavior of lld during LTO for global symbols (Attr Internal/Common) [CAUTION: External

When using the ARM cross compiler we've run into an issue with LTO and optimized libraries. Consider you have an optimized library opt.a, which contains a version of memcpy. Compiling with LTO (something like), clang myTest.c opt.a -flto -o myTest causes myTest.c to get compiled to bitcode. Then the bitcode gets passed to the linker. The linker looks through the bitcode (via

Hi, I have tried to build libjpeg-turbo <https://github.com/libjpeg-turbo/libjpeg-turbo> with LTO in LLVM, using both clangbut get many errors in lld that look like the following: ld: error: undefined symbol: jpeg_std_error >>> referenced by jcstest.c:76 >>> lto.tmp:(main) ld: error: undefined symbol: jpeg_CreateCompress >>> referenced by

Adding a couple of lld folks. I helped Shishir debug this, the link line looked like: /home/sjessu/build/bin/clang -O0 -flto -o jcstest jcstest.o ./.libs/libjpeg.a and the issue was that libjpeg.a was created with the system ar instead of llvm-ar. It worked when recreating libjpeg.a with llvm-ar. I noticed that the lld code has some special handling for the case when there is a missing

Thanks for your response! On 30/01/2019 20:18, Rui Ueyama wrote: > Hi Josef, > > Let me clarify my understanding. Do you want to keep original bitcode > files in the output executable when doing LTO, so that the resulting > executable contains both compiled bitcode (which is in native machine > instructions) and original bitcode files? Exactly! Kind of analogous to what

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 Thu, Jan 31, 2019 at 11:05 AM Rui Ueyama via llvm-dev < llvm-dev at lists.llvm.org> wrote: > That feature is probably too specific to your project. Most projects that > use LTO are using LTO just because it generates better code. Your project > is special as your program itself can also interpret LLVM bitcode, but > that's not the case for most other programs. > I

Hi: &nbsp; &nbsp; I want to learn&nbsp; how LTO and thinLTO work? But I'm confused how lld invoked either library. How can I find it in lld. Should i be familiar with lld source code? And i also think if there is some easy test case and with step-by- step debugging or some log messages can help me learn this? Is there some method can do stuff like this? &nbsp; Thank you very

Hi everybody! I'm Josef and I'm working at Oracle Labs on Sulong [1,2], the LLVM IR execution engine in GraalVM [3]. In addition to executing bare bitcode files, Sulong also accepts ELF files with embedded bitcode sections. Therefore, it would be great if LLD in (Full)LTO mode would support embedding bitcode sections to the resulting object file. Is that something that would be

> On 2015-Aug-31, at 12:21, Eric Christopher <echristo at gmail.com> wrote: > Yep. This is where I was going :) Glad I found consensus, but I want to double-check that this makes sense to add to the driver. I didn't quite think through the implications myself. Since the driver doesn't know if there's any bitcode, or if LTO is going to be invoked, it seems like I'll

Hi Teresa, Can you please let me know if there is any update on this issue. Thanks M Suresh From: Teresa Johnson <tejohnson at google.com> Sent: Tuesday, June 11, 2019 7:23 PM To: Rui Ueyama <ruiu at google.com> Cc: Mani, Suresh <Suresh.Mani at amd.com>; llvm-dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] Expected behavior of lld during LTO for global symbols

This one triggers an assertion in calculateSEHStateNumbers due to weird catchpad instruction in @_island_debug_invoke and many other functions. The code expects either pointer to a filter function or null in first operand, while you're passing pointer to structure: catchpad within %80 [{i8*, i8*}* anon..., ...] ________________________________________ От: Carlo Kok <ck at

Op 16-3-2018 om 20:16 schreef Evgeny Leviant: > Hello Carlo, > > I tried your reproducer and faced different problem from one you described > (I'm using MacOS Sierra and lld built from trunk on Mar, 15). The crash happens > when SelectionDAGBuilder::lowerInvokable tries to access EH info of this function: > >