Rui Ueyama via llvm-dev
2019-Feb-28 00:00 UTC
[llvm-dev] 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 translation tool. If you are now doing a regular cross build, I guess you can remove -flto. On Wed, Feb 27, 2019 at 3:00 PM Rui Ueyama <ruiu at google.com> wrote:> Hi Steven, > > I confirmed that lld-link crashes with these inputs. That shouldn't > happen. I'll debug this and get back to you. Thank you for reporting. > > On Tue, Feb 26, 2019 at 8:20 PM Shi, Steven <steven.shi at intel.com> wrote: > >> 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 >> /ENTRY:main main.obj intrinsics.obj”, the below example can pass link. >> Please advise what’s wrong in this example. >> >> >> >> >> >> $ cat main.c >> >> typedef struct { >> >> struct MAP_LIST { >> >> unsigned long long VirtualAddress; >> >> void *MapCookie; >> >> } MapList[100]; >> >> } SNP_DRIVER; >> >> SNP_DRIVER snp_instance; >> >> int main() >> >> { >> >> SNP_DRIVER *Snp; >> >> Snp = &snp_instance; >> >> for (int Index = 0; Index < 100; Index++) { >> >> Snp->MapList[Index].VirtualAddress = 0; >> >> Snp->MapList[Index].MapCookie = 0; >> >> } >> >> return 0; >> >> } >> >> >> >> $ cat intrinsics.c >> >> void * memset (void *dest, int ch, size_t count) >> >> { >> >> volatile char *Pointer; >> >> Pointer = (char *)dest; >> >> while (count-- != 0) { >> >> *(Pointer++) = (char)ch; >> >> } >> >> return dest; >> >> } >> >> >> >> >> >> $ "/home/jshi19/llvm/releaseinstall/bin/clang-cl" /Fomain.obj /c >> --target=x86_64-pc-win32-coff -m64 /O1b2s -flto main.c >> >> $ "/home/jshi19/llvm/releaseinstall/bin/clang-cl" /Fointrinsics.obj /c >> --target=x86_64-pc-win32-coff -m64 /O1b2s -flto intrinsics.c >> >> $ "/home/jshi19/llvm/releaseinstall/bin/llvm-lib" /OUT:intrinsics.lib >> intrinsics.obj >> >> $ "/home/jshi19/llvm/releaseinstall/bin/lld-link" /NODEFAULTLIB >> /ENTRY:main main.obj intrinsics.lib >> >> Stack dump: >> >> 0. Program arguments: /home/jshi19/llvm/releaseinstall/bin/lld-link >> /NODEFAULTLIB /ENTRY:main main.obj intrinsics.lib >> >> #0 0x0000559a34ba5e4a llvm::sys::PrintStackTrace(llvm::raw_ostream&) >> (/home/jshi19/llvm/releaseinstall/bin/lld-link+0x272e4a) >> >> #1 0x0000559a34ba3d14 llvm::sys::RunSignalHandlers() >> (/home/jshi19/llvm/releaseinstall/bin/lld-link+0x270d14) >> >> #2 0x0000559a34ba3e52 SignalHandler(int) >> (/home/jshi19/llvm/releaseinstall/bin/lld-link+0x270e52) >> >> #3 0x00007f896c8ea890 __restore_rt >> (/lib/x86_64-linux-gnu/libpthread.so.0+0x12890) >> >> #4 0x0000559a34c11325 >> lld::coff::markLive(llvm::ArrayRef<lld::coff::Chunk*>) >> (/home/jshi19/llvm/releaseinstall/bin/lld-link+0x2de325) >> >> #5 0x0000559a34bf0220 lld::coff::LinkerDriver::link(llvm::ArrayRef<char >> const*>) (/home/jshi19/llvm/releaseinstall/bin/lld-link+0x2bd220) >> >> #6 0x0000559a34bf0478 lld::coff::link(llvm::ArrayRef<char const*>, bool, >> llvm::raw_ostream&) (/home/jshi19/llvm/releaseinstall/bin/lld-link+0x2bd478) >> >> #7 0x0000559a34b2a300 main >> (/home/jshi19/llvm/releaseinstall/bin/lld-link+0x1f7300) >> >> #8 0x00007f896b3c1b97 __libc_start_main >> /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:344:0 >> >> #9 0x0000559a34b8c27a _start >> (/home/jshi19/llvm/releaseinstall/bin/lld-link+0x25927a) >> >> Segmentation fault (core dumped) >> >> >> >> $ "/home/jshi19/llvm/releaseinstall/bin/clang-cl" --version >> >> clang version 9.0.0 (https://github.com/llvm-mirror/clang.git >> 1f02068469ff18f5fc5728cafe9d96ee5f66c5b9) ( >> https://github.com/llvm-project/llvm.git >> 330395ea4fce35b019b33797ff751be029a1f866) >> >> Target: x86_64-pc-windows-msvc >> >> Thread model: posix >> >> InstalledDir: /home/jshi19/llvm/releaseinstall/bin >> >> >> >> $ "/home/jshi19/llvm/releaseinstall/bin/lld-link" --version >> >> LLD 9.0.0 (https://github.com/llvm-mirror/lld.git >> aa7adc0ec804b689771f11d52e39f83a16378f5f) >> >> >> >> >> >> >> >> >> >> Thanks >> >> >> >> *Steven Shi* >> >> *Intel\SSG\FID\Firmware Infrastructure* >> >> >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190227/93aab076/attachment.html>
Peter Collingbourne via llvm-dev
2019-Feb-28 00:05 UTC
[llvm-dev] lld-link crash when linking intrinsics lib
Hmm, you might need something like the ELF linker's r338434/r339301 in the COFF linker. Peter On Wed, Feb 27, 2019 at 4:01 PM Rui Ueyama <ruiu at google.com> wrote:> +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 translation tool. > If you are now doing a regular cross build, I guess you can remove -flto. > > On Wed, Feb 27, 2019 at 3:00 PM Rui Ueyama <ruiu at google.com> wrote: > >> Hi Steven, >> >> I confirmed that lld-link crashes with these inputs. That shouldn't >> happen. I'll debug this and get back to you. Thank you for reporting. >> >> On Tue, Feb 26, 2019 at 8:20 PM Shi, Steven <steven.shi at intel.com> wrote: >> >>> 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 >>> /ENTRY:main main.obj intrinsics.obj”, the below example can pass link. >>> Please advise what’s wrong in this example. >>> >>> >>> >>> >>> >>> $ cat main.c >>> >>> typedef struct { >>> >>> struct MAP_LIST { >>> >>> unsigned long long VirtualAddress; >>> >>> void *MapCookie; >>> >>> } MapList[100]; >>> >>> } SNP_DRIVER; >>> >>> SNP_DRIVER snp_instance; >>> >>> int main() >>> >>> { >>> >>> SNP_DRIVER *Snp; >>> >>> Snp = &snp_instance; >>> >>> for (int Index = 0; Index < 100; Index++) { >>> >>> Snp->MapList[Index].VirtualAddress = 0; >>> >>> Snp->MapList[Index].MapCookie = 0; >>> >>> } >>> >>> return 0; >>> >>> } >>> >>> >>> >>> $ cat intrinsics.c >>> >>> void * memset (void *dest, int ch, size_t count) >>> >>> { >>> >>> volatile char *Pointer; >>> >>> Pointer = (char *)dest; >>> >>> while (count-- != 0) { >>> >>> *(Pointer++) = (char)ch; >>> >>> } >>> >>> return dest; >>> >>> } >>> >>> >>> >>> >>> >>> $ "/home/jshi19/llvm/releaseinstall/bin/clang-cl" /Fomain.obj /c >>> --target=x86_64-pc-win32-coff -m64 /O1b2s -flto main.c >>> >>> $ "/home/jshi19/llvm/releaseinstall/bin/clang-cl" /Fointrinsics.obj /c >>> --target=x86_64-pc-win32-coff -m64 /O1b2s -flto intrinsics.c >>> >>> $ "/home/jshi19/llvm/releaseinstall/bin/llvm-lib" /OUT:intrinsics.lib >>> intrinsics.obj >>> >>> $ "/home/jshi19/llvm/releaseinstall/bin/lld-link" /NODEFAULTLIB >>> /ENTRY:main main.obj intrinsics.lib >>> >>> Stack dump: >>> >>> 0. Program arguments: /home/jshi19/llvm/releaseinstall/bin/lld-link >>> /NODEFAULTLIB /ENTRY:main main.obj intrinsics.lib >>> >>> #0 0x0000559a34ba5e4a llvm::sys::PrintStackTrace(llvm::raw_ostream&) >>> (/home/jshi19/llvm/releaseinstall/bin/lld-link+0x272e4a) >>> >>> #1 0x0000559a34ba3d14 llvm::sys::RunSignalHandlers() >>> (/home/jshi19/llvm/releaseinstall/bin/lld-link+0x270d14) >>> >>> #2 0x0000559a34ba3e52 SignalHandler(int) >>> (/home/jshi19/llvm/releaseinstall/bin/lld-link+0x270e52) >>> >>> #3 0x00007f896c8ea890 __restore_rt >>> (/lib/x86_64-linux-gnu/libpthread.so.0+0x12890) >>> >>> #4 0x0000559a34c11325 >>> lld::coff::markLive(llvm::ArrayRef<lld::coff::Chunk*>) >>> (/home/jshi19/llvm/releaseinstall/bin/lld-link+0x2de325) >>> >>> #5 0x0000559a34bf0220 lld::coff::LinkerDriver::link(llvm::ArrayRef<char >>> const*>) (/home/jshi19/llvm/releaseinstall/bin/lld-link+0x2bd220) >>> >>> #6 0x0000559a34bf0478 lld::coff::link(llvm::ArrayRef<char const*>, bool, >>> llvm::raw_ostream&) (/home/jshi19/llvm/releaseinstall/bin/lld-link+0x2bd478) >>> >>> #7 0x0000559a34b2a300 main >>> (/home/jshi19/llvm/releaseinstall/bin/lld-link+0x1f7300) >>> >>> #8 0x00007f896b3c1b97 __libc_start_main >>> /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:344:0 >>> >>> #9 0x0000559a34b8c27a _start >>> (/home/jshi19/llvm/releaseinstall/bin/lld-link+0x25927a) >>> >>> Segmentation fault (core dumped) >>> >>> >>> >>> $ "/home/jshi19/llvm/releaseinstall/bin/clang-cl" --version >>> >>> clang version 9.0.0 (https://github.com/llvm-mirror/clang.git >>> 1f02068469ff18f5fc5728cafe9d96ee5f66c5b9) ( >>> https://github.com/llvm-project/llvm.git >>> 330395ea4fce35b019b33797ff751be029a1f866) >>> >>> Target: x86_64-pc-windows-msvc >>> >>> Thread model: posix >>> >>> InstalledDir: /home/jshi19/llvm/releaseinstall/bin >>> >>> >>> >>> $ "/home/jshi19/llvm/releaseinstall/bin/lld-link" --version >>> >>> LLD 9.0.0 (https://github.com/llvm-mirror/lld.git >>> aa7adc0ec804b689771f11d52e39f83a16378f5f) >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Thanks >>> >>> >>> >>> *Steven Shi* >>> >>> *Intel\SSG\FID\Firmware Infrastructure* >>> >>> >>> >>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190227/f26580ca/attachment.html>
Shi, Steven via llvm-dev
2019-Feb-28 00:11 UTC
[llvm-dev] lld-link crash when linking intrinsics lib
>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 translation tool. If you are now doing a regular cross build, I guess you can remove -flto.Yes, I need the LTO for the smallest code size. Without LTO, my firmware image will be +30% larger which is not competitive with MSVC. Thanks Steven From: Rui Ueyama [mailto:ruiu at google.com] Sent: Thursday, February 28, 2019 8:01 AM To: Shi, Steven <steven.shi at intel.com>; Peter Collingbourne <pcc at chromium.org> Cc: Peter Smith <peter.smith at linaro.org>; Martin Storsjö <martin at martin.st>; llvm-dev at lists.llvm.org Subject: Re: lld-link crash when linking intrinsics lib +Peter Collingbourne<mailto: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 translation tool. If you are now doing a regular cross build, I guess you can remove -flto. On Wed, Feb 27, 2019 at 3:00 PM Rui Ueyama <ruiu at google.com<mailto:ruiu at google.com>> wrote: Hi Steven, I confirmed that lld-link crashes with these inputs. That shouldn't happen. I'll debug this and get back to you. Thank you for reporting. On Tue, Feb 26, 2019 at 8:20 PM Shi, Steven <steven.shi at intel.com<mailto:steven.shi at intel.com>> wrote: 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 /ENTRY:main main.obj intrinsics.obj”, the below example can pass link. Please advise what’s wrong in this example. $ cat main.c typedef struct { struct MAP_LIST { unsigned long long VirtualAddress; void *MapCookie; } MapList[100]; } SNP_DRIVER; SNP_DRIVER snp_instance; int main() { SNP_DRIVER *Snp; Snp = &snp_instance; for (int Index = 0; Index < 100; Index++) { Snp->MapList[Index].VirtualAddress = 0; Snp->MapList[Index].MapCookie = 0; } return 0; } $ cat intrinsics.c void * memset (void *dest, int ch, size_t count) { volatile char *Pointer; Pointer = (char *)dest; while (count-- != 0) { *(Pointer++) = (char)ch; } return dest; } $ "/home/jshi19/llvm/releaseinstall/bin/clang-cl" /Fomain.obj /c --target=x86_64-pc-win32-coff -m64 /O1b2s -flto main.c $ "/home/jshi19/llvm/releaseinstall/bin/clang-cl" /Fointrinsics.obj /c --target=x86_64-pc-win32-coff -m64 /O1b2s -flto intrinsics.c $ "/home/jshi19/llvm/releaseinstall/bin/llvm-lib" /OUT:intrinsics.lib intrinsics.obj $ "/home/jshi19/llvm/releaseinstall/bin/lld-link" /NODEFAULTLIB /ENTRY:main main.obj intrinsics.lib Stack dump: 0. Program arguments: /home/jshi19/llvm/releaseinstall/bin/lld-link /NODEFAULTLIB /ENTRY:main main.obj intrinsics.lib #0 0x0000559a34ba5e4a llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/home/jshi19/llvm/releaseinstall/bin/lld-link+0x272e4a) #1 0x0000559a34ba3d14 llvm::sys::RunSignalHandlers() (/home/jshi19/llvm/releaseinstall/bin/lld-link+0x270d14) #2 0x0000559a34ba3e52 SignalHandler(int) (/home/jshi19/llvm/releaseinstall/bin/lld-link+0x270e52) #3 0x00007f896c8ea890 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x12890) #4 0x0000559a34c11325 lld::coff::markLive(llvm::ArrayRef<lld::coff::Chunk*>) (/home/jshi19/llvm/releaseinstall/bin/lld-link+0x2de325) #5 0x0000559a34bf0220 lld::coff::LinkerDriver::link(llvm::ArrayRef<char const*>) (/home/jshi19/llvm/releaseinstall/bin/lld-link+0x2bd220) #6 0x0000559a34bf0478 lld::coff::link(llvm::ArrayRef<char const*>, bool, llvm::raw_ostream&) (/home/jshi19/llvm/releaseinstall/bin/lld-link+0x2bd478) #7 0x0000559a34b2a300 main (/home/jshi19/llvm/releaseinstall/bin/lld-link+0x1f7300) #8 0x00007f896b3c1b97 __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:344:0 #9 0x0000559a34b8c27a _start (/home/jshi19/llvm/releaseinstall/bin/lld-link+0x25927a) Segmentation fault (core dumped) $ "/home/jshi19/llvm/releaseinstall/bin/clang-cl" --version clang version 9.0.0 (https://github.com/llvm-mirror/clang.git 1f02068469ff18f5fc5728cafe9d96ee5f66c5b9) (https://github.com/llvm-project/llvm.git 330395ea4fce35b019b33797ff751be029a1f866) Target: x86_64-pc-windows-msvc Thread model: posix InstalledDir: /home/jshi19/llvm/releaseinstall/bin $ "/home/jshi19/llvm/releaseinstall/bin/lld-link" --version LLD 9.0.0 (https://github.com/llvm-mirror/lld.git aa7adc0ec804b689771f11d52e39f83a16378f5f) Thanks Steven Shi Intel\SSG\FID\Firmware Infrastructure -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190228/fb67a9d9/attachment-0001.html>
Rui Ueyama via llvm-dev
2019-Feb-28 00:15 UTC
[llvm-dev] lld-link crash when linking intrinsics lib
On Wed, Feb 27, 2019 at 4:11 PM Shi, Steven <steven.shi at intel.com> wrote:> >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 translation tool. > If you are now doing a regular cross build, I guess you can remove -flto. > > Yes, I need the LTO for the smallest code size. Without LTO, my firmware > image will be +30% larger which is not competitive with MSVC. >In the meantime you probably want to experiment clang-cl and lld without -flto. Once this issue is resolved, you can turn it on. Thanks> > Steven > > > > *From:* Rui Ueyama [mailto:ruiu at google.com] > *Sent:* Thursday, February 28, 2019 8:01 AM > *To:* Shi, Steven <steven.shi at intel.com>; Peter Collingbourne < > pcc at chromium.org> > *Cc:* Peter Smith <peter.smith at linaro.org>; Martin Storsjö < > martin at martin.st>; llvm-dev at lists.llvm.org > *Subject:* Re: 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 translation tool. > If you are now doing a regular cross build, I guess you can remove -flto. > > > > On Wed, Feb 27, 2019 at 3:00 PM Rui Ueyama <ruiu at google.com> wrote: > > Hi Steven, > > > > I confirmed that lld-link crashes with these inputs. That shouldn't > happen. I'll debug this and get back to you. Thank you for reporting. > > > > On Tue, Feb 26, 2019 at 8:20 PM Shi, Steven <steven.shi at intel.com> wrote: > > 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 > /ENTRY:main main.obj intrinsics.obj”, the below example can pass link. > Please advise what’s wrong in this example. > > > > > > $ cat main.c > > typedef struct { > > struct MAP_LIST { > > unsigned long long VirtualAddress; > > void *MapCookie; > > } MapList[100]; > > } SNP_DRIVER; > > SNP_DRIVER snp_instance; > > int main() > > { > > SNP_DRIVER *Snp; > > Snp = &snp_instance; > > for (int Index = 0; Index < 100; Index++) { > > Snp->MapList[Index].VirtualAddress = 0; > > Snp->MapList[Index].MapCookie = 0; > > } > > return 0; > > } > > > > $ cat intrinsics.c > > void * memset (void *dest, int ch, size_t count) > > { > > volatile char *Pointer; > > Pointer = (char *)dest; > > while (count-- != 0) { > > *(Pointer++) = (char)ch; > > } > > return dest; > > } > > > > > > $ "/home/jshi19/llvm/releaseinstall/bin/clang-cl" /Fomain.obj /c > --target=x86_64-pc-win32-coff -m64 /O1b2s -flto main.c > > $ "/home/jshi19/llvm/releaseinstall/bin/clang-cl" /Fointrinsics.obj /c > --target=x86_64-pc-win32-coff -m64 /O1b2s -flto intrinsics.c > > $ "/home/jshi19/llvm/releaseinstall/bin/llvm-lib" /OUT:intrinsics.lib > intrinsics.obj > > $ "/home/jshi19/llvm/releaseinstall/bin/lld-link" /NODEFAULTLIB > /ENTRY:main main.obj intrinsics.lib > > Stack dump: > > 0. Program arguments: /home/jshi19/llvm/releaseinstall/bin/lld-link > /NODEFAULTLIB /ENTRY:main main.obj intrinsics.lib > > #0 0x0000559a34ba5e4a llvm::sys::PrintStackTrace(llvm::raw_ostream&) > (/home/jshi19/llvm/releaseinstall/bin/lld-link+0x272e4a) > > #1 0x0000559a34ba3d14 llvm::sys::RunSignalHandlers() > (/home/jshi19/llvm/releaseinstall/bin/lld-link+0x270d14) > > #2 0x0000559a34ba3e52 SignalHandler(int) > (/home/jshi19/llvm/releaseinstall/bin/lld-link+0x270e52) > > #3 0x00007f896c8ea890 __restore_rt > (/lib/x86_64-linux-gnu/libpthread.so.0+0x12890) > > #4 0x0000559a34c11325 > lld::coff::markLive(llvm::ArrayRef<lld::coff::Chunk*>) > (/home/jshi19/llvm/releaseinstall/bin/lld-link+0x2de325) > > #5 0x0000559a34bf0220 lld::coff::LinkerDriver::link(llvm::ArrayRef<char > const*>) (/home/jshi19/llvm/releaseinstall/bin/lld-link+0x2bd220) > > #6 0x0000559a34bf0478 lld::coff::link(llvm::ArrayRef<char const*>, bool, > llvm::raw_ostream&) (/home/jshi19/llvm/releaseinstall/bin/lld-link+0x2bd478) > > #7 0x0000559a34b2a300 main > (/home/jshi19/llvm/releaseinstall/bin/lld-link+0x1f7300) > > #8 0x00007f896b3c1b97 __libc_start_main > /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:344:0 > > #9 0x0000559a34b8c27a _start > (/home/jshi19/llvm/releaseinstall/bin/lld-link+0x25927a) > > Segmentation fault (core dumped) > > > > $ "/home/jshi19/llvm/releaseinstall/bin/clang-cl" --version > > clang version 9.0.0 (https://github.com/llvm-mirror/clang.git > 1f02068469ff18f5fc5728cafe9d96ee5f66c5b9) ( > https://github.com/llvm-project/llvm.git > 330395ea4fce35b019b33797ff751be029a1f866) > > Target: x86_64-pc-windows-msvc > > Thread model: posix > > InstalledDir: /home/jshi19/llvm/releaseinstall/bin > > > > $ "/home/jshi19/llvm/releaseinstall/bin/lld-link" --version > > LLD 9.0.0 (https://github.com/llvm-mirror/lld.git > aa7adc0ec804b689771f11d52e39f83a16378f5f) > > > > > > > > > > Thanks > > > > *Steven Shi* > > *Intel\SSG\FID\Firmware Infrastructure* > > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190227/940fa7ed/attachment.html>
Rui Ueyama via llvm-dev
2019-Feb-28 00:16 UTC
[llvm-dev] lld-link crash when linking intrinsics lib
On Wed, Feb 27, 2019 at 4:05 PM Peter Collingbourne <pcc at google.com> wrote:> Hmm, you might need something like the ELF linker's r338434/r339301 in the > COFF linker. >Are you going to do that? If we need to port it in a straightforward way, I think I can do that, though. Peter> > On Wed, Feb 27, 2019 at 4:01 PM Rui Ueyama <ruiu at google.com> wrote: > >> +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 translation tool. >> If you are now doing a regular cross build, I guess you can remove -flto. >> >> On Wed, Feb 27, 2019 at 3:00 PM Rui Ueyama <ruiu at google.com> wrote: >> >>> Hi Steven, >>> >>> I confirmed that lld-link crashes with these inputs. That shouldn't >>> happen. I'll debug this and get back to you. Thank you for reporting. >>> >>> On Tue, Feb 26, 2019 at 8:20 PM Shi, Steven <steven.shi at intel.com> >>> wrote: >>> >>>> 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 >>>> /ENTRY:main main.obj intrinsics.obj”, the below example can pass link. >>>> Please advise what’s wrong in this example. >>>> >>>> >>>> >>>> >>>> >>>> $ cat main.c >>>> >>>> typedef struct { >>>> >>>> struct MAP_LIST { >>>> >>>> unsigned long long VirtualAddress; >>>> >>>> void *MapCookie; >>>> >>>> } MapList[100]; >>>> >>>> } SNP_DRIVER; >>>> >>>> SNP_DRIVER snp_instance; >>>> >>>> int main() >>>> >>>> { >>>> >>>> SNP_DRIVER *Snp; >>>> >>>> Snp = &snp_instance; >>>> >>>> for (int Index = 0; Index < 100; Index++) { >>>> >>>> Snp->MapList[Index].VirtualAddress = 0; >>>> >>>> Snp->MapList[Index].MapCookie = 0; >>>> >>>> } >>>> >>>> return 0; >>>> >>>> } >>>> >>>> >>>> >>>> $ cat intrinsics.c >>>> >>>> void * memset (void *dest, int ch, size_t count) >>>> >>>> { >>>> >>>> volatile char *Pointer; >>>> >>>> Pointer = (char *)dest; >>>> >>>> while (count-- != 0) { >>>> >>>> *(Pointer++) = (char)ch; >>>> >>>> } >>>> >>>> return dest; >>>> >>>> } >>>> >>>> >>>> >>>> >>>> >>>> $ "/home/jshi19/llvm/releaseinstall/bin/clang-cl" /Fomain.obj /c >>>> --target=x86_64-pc-win32-coff -m64 /O1b2s -flto main.c >>>> >>>> $ "/home/jshi19/llvm/releaseinstall/bin/clang-cl" /Fointrinsics.obj /c >>>> --target=x86_64-pc-win32-coff -m64 /O1b2s -flto intrinsics.c >>>> >>>> $ "/home/jshi19/llvm/releaseinstall/bin/llvm-lib" /OUT:intrinsics.lib >>>> intrinsics.obj >>>> >>>> $ "/home/jshi19/llvm/releaseinstall/bin/lld-link" /NODEFAULTLIB >>>> /ENTRY:main main.obj intrinsics.lib >>>> >>>> Stack dump: >>>> >>>> 0. Program arguments: >>>> /home/jshi19/llvm/releaseinstall/bin/lld-link /NODEFAULTLIB /ENTRY:main >>>> main.obj intrinsics.lib >>>> >>>> #0 0x0000559a34ba5e4a llvm::sys::PrintStackTrace(llvm::raw_ostream&) >>>> (/home/jshi19/llvm/releaseinstall/bin/lld-link+0x272e4a) >>>> >>>> #1 0x0000559a34ba3d14 llvm::sys::RunSignalHandlers() >>>> (/home/jshi19/llvm/releaseinstall/bin/lld-link+0x270d14) >>>> >>>> #2 0x0000559a34ba3e52 SignalHandler(int) >>>> (/home/jshi19/llvm/releaseinstall/bin/lld-link+0x270e52) >>>> >>>> #3 0x00007f896c8ea890 __restore_rt >>>> (/lib/x86_64-linux-gnu/libpthread.so.0+0x12890) >>>> >>>> #4 0x0000559a34c11325 >>>> lld::coff::markLive(llvm::ArrayRef<lld::coff::Chunk*>) >>>> (/home/jshi19/llvm/releaseinstall/bin/lld-link+0x2de325) >>>> >>>> #5 0x0000559a34bf0220 lld::coff::LinkerDriver::link(llvm::ArrayRef<char >>>> const*>) (/home/jshi19/llvm/releaseinstall/bin/lld-link+0x2bd220) >>>> >>>> #6 0x0000559a34bf0478 lld::coff::link(llvm::ArrayRef<char const*>, >>>> bool, llvm::raw_ostream&) >>>> (/home/jshi19/llvm/releaseinstall/bin/lld-link+0x2bd478) >>>> >>>> #7 0x0000559a34b2a300 main >>>> (/home/jshi19/llvm/releaseinstall/bin/lld-link+0x1f7300) >>>> >>>> #8 0x00007f896b3c1b97 __libc_start_main >>>> /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:344:0 >>>> >>>> #9 0x0000559a34b8c27a _start >>>> (/home/jshi19/llvm/releaseinstall/bin/lld-link+0x25927a) >>>> >>>> Segmentation fault (core dumped) >>>> >>>> >>>> >>>> $ "/home/jshi19/llvm/releaseinstall/bin/clang-cl" --version >>>> >>>> clang version 9.0.0 (https://github.com/llvm-mirror/clang.git >>>> 1f02068469ff18f5fc5728cafe9d96ee5f66c5b9) ( >>>> https://github.com/llvm-project/llvm.git >>>> 330395ea4fce35b019b33797ff751be029a1f866) >>>> >>>> Target: x86_64-pc-windows-msvc >>>> >>>> Thread model: posix >>>> >>>> InstalledDir: /home/jshi19/llvm/releaseinstall/bin >>>> >>>> >>>> >>>> $ "/home/jshi19/llvm/releaseinstall/bin/lld-link" --version >>>> >>>> LLD 9.0.0 (https://github.com/llvm-mirror/lld.git >>>> aa7adc0ec804b689771f11d52e39f83a16378f5f) >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Thanks >>>> >>>> >>>> >>>> *Steven Shi* >>>> >>>> *Intel\SSG\FID\Firmware Infrastructure* >>>> >>>> >>>> >>>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190227/f2d993f0/attachment.html>