similar to: lld-link crash when build openssl with LTO

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

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

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

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

Hello Rui, I met couples of lld-link crash when enable the clang-cl + lld-link build toolchain for Uefi firmware. Below is a simplified example (main.c and intrinsics.c). Uefi firmware is self-contained and doesn't depend on the compiler intrinsics implementation, so we have our own intrinsics lib. It is weird that if I don't use the llvm-lib but directly "lld-link /NODEFAULTLIB

+Peter Collingbourne <pcc at chromium.org> LTO is used in this test case, and one source file defines its own `memset` function while the other file uses llvm.memset. Looks like LTO is confused by the user-defined memset. Could you take a look? Steven, Do you need to use LTO? I thought that LTO is a workaround to not produce an object file that cannot be handled by your ELF-to-COFF

Hello Rui, We meet an LLD PDB issue that if we link assembly code with C code and set >= -O1 level optimization in LTO, the executable's PDB will contain wrong zero Lines for the assembly code in DEBUG_S_LINES subsection, and then our COFF source debuggers will fail to do the source-level debug on the executable. This issue is same in both Linux and Windows, and I figure out a simple case

Hi Rui, We meet a problem when enable the execute in place (XIP, https://en.wikipedia.org/wiki/Execute_in_place) for uefi firmware with lld-link. We need to set the COFF executable file SectionAlignment through the lld-link /ALIGN option, but we find the SectionAlignment is hardcoded to 4096 which cause the /ALIGN option doesn't work at all. Below is the hardcode in lld: lld\COFF\Writer.h

Hi Rui, I still fail to enable the lld in my Uefi firmware build to replace ld, and I found it is related to the wrong symbol values in the .data section, which are pointed by R_X86_64_64 relocation entries. I need your advices. My firmware uses a linker script https://github.com/tianocore/edk2/blob/master/BaseTools/Scripts/GccBase.lds to do the linking. We use position independent code with

Hi Rui, > but why don't you use lld-link (lld for Windows target) instead of ld.lld (lld for Unix target) to create UEFI applications? I need support both PE/COFF and ELF format tools. I’m also working on the lld-link enabling (clang-cl + lld-link) in both Linux and windows. The ld.lld enabling (clang + ld.lld) is for ELF format native users. E.g.

Hi Rui, A quick question: Does lld-link only work with clang-cl with windows-msvc option? Can lld-link work with clang with linux-gnu option? Thanks Steven Shi Intel\SSG\FID\Firmware Infrastructure From: Shi, Steven Sent: Tuesday, January 29, 2019 1:32 PM To: 'Rui Ueyama' <ruiu at google.com> Cc: llvm-dev at lists.llvm.org Subject: RE: lld write wrong symbol value in .data

Hi Rui, Peter, You know I'm enabling the "clang-cl + lld-link" toolchain for Uefi firmware. I meet a problem that the lld-link fails to link 32bits assembly functions, but can link 64bits assembly functions successfully. I need your suggestion. Below is an example to show my problem in linux. The example has two only source files: main.c and foo.nasm. $ cat main.c void Foo (void);

Hi Mehdi, The llvm3.8 gold-plugin.cpp is very different from the latest one on trunk. Your patch has compiling failure on llvm3.8 as below. I will try it on latest trunk later. Thank you help anyway! Building CXX object tools/gold/CMakeFiles/LLVMgold.dir/gold-plugin.cpp.o cd /home/jshi19/llvm38releasebuild/tools/gold && /home/jshi19/clang38/bin/clang++ -DGTEST_HAS_RTTI=0

I checked the LLVM master code and find that the “-use-unknown-locations” option and its related logic is only supported for Dwarf debug info as below. These codes are missing in the Codeview side. It looks the “-use-unknown-locations” option logic is not complex, could we port the code logic into llvm\lib\CodeGen\AsmPrinter\CodeViewDebug.cpp as well? I’ve submitted a BZ for this requirment:

OK, maybe I was wrong and the “-use-unknown-locations” option is not the issue root cause. I'm not familiar with the LLVM codebase and I appreciate any suggestion on how to debug this issue. I'd like to know is it a clang issue or a lld issue? Is there a tool which can dump the obj file debug location info? Let me simplify the previous test case to reproduce this issue. All what you need

Hi Martin, Thank you for the hint. > For 32 bit windows, functions with cdecl calling convention (the default > in C) are decorated with an underscore prefix. So you'd need to update > your nasm source file to define the symbol _Foo instead of Foo. (Most > assembly files use some sort of macro for wrapping this detail.) Yes, my assembly files do use prefix macro (ASM_PFX) for

The opus code default compiles on -o2 optimization level. I would like to change it to -o3. I have tried doing the changes in makefile.unix . The change is not getting reflected. I am building the code in Code composer studio for TI processor C6000. Could anybody help me with this -------------- next part -------------- An HTML attachment was scrubbed... URL:

I didn't try to compile it locally (I don't have/use gold), but you should be able to fix the 3 errors fairly easily (looks like missing includes mostly). -- Mehdi > On May 30, 2016, at 5:11 AM, Shi, Steven <steven.shi at intel.com> wrote: > > Hi Mehdi, > Your patch cannot compile with gold-plugin.cpp in latest trunk either, the failure is same as llvm3.8 as below.

Hi Steven, > On May 29, 2016, at 11:28 PM, Shi, Steven <steven.shi at intel.com> wrote: > > Hi Mehdi, > Should I apply your attached patch on my llvm3.8 source firstly? Or should I use the latest llvm SVN trunk instead? I wrote it on trunk, but I expect it to be fairly easy to port on 3.8. This is really just quickly plumbing an option on the TargetMachine creation. --

Hi Richard, Thank you for the info. I build my code in Ubuntu-64bits with simply commands: “clang X64.c”, then run “./a.out” to see the output. If I replace my va_list, va_start, va_arg va_end with __builtin_ms_va_list, __builtin_ms_va_start, __builtin_ms_va_arg, __builtin_ms_va_end, my code will build fail in Ubuntu with below message. Do you suggest I should build it in windows and not in