similar to: lld-link crash when linking intrinsics lib

+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

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

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

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,

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

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

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

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

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

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

On Thu, 9 Jan 2020, David Blaikie via llvm-dev wrote: > +rnk who works on COFF debugging things. > >  My understanding is that this has nothing to do with the linker - but is a > function of LLVM optimizations creating line zero debug locations. I believe > rnk & folks have disabled line zero emission for CodeView debug info in some > manner - perhaps that needs a flag? or