2015-08-07 00:47:46 +08:00
|
|
|
# RUN: not lld-link nosuchfile.obj >& %t.log
|
2021-01-29 20:15:50 +08:00
|
|
|
# RUN: FileCheck -DMSG=%errc_ENOENT -check-prefix=MISSING %s < %t.log
|
|
|
|
|
MISSING: 'nosuchfile.obj': [[MSG]]
|
2017-10-23 22:57:53 +08:00
|
|
|
|
|
|
|
|
# RUN: lld-link --version | FileCheck -check-prefix=VERSION %s
|
|
|
|
|
VERSION: {{LLD [0-9]+\.[0-9]+}}
|
2018-03-02 07:11:30 +08:00
|
|
|
|
2020-08-21 06:00:25 +08:00
|
|
|
# RUN: yaml2obj %p/Inputs/export.yaml -o %t.obj
|
2018-03-02 07:11:30 +08:00
|
|
|
# RUN: lld-link /out:%t.dll /dll %t.obj
|
|
|
|
|
# RUN: not lld-link /out:%t.exe %t.dll 2>&1 | FileCheck -check-prefix=BADFILE %s
|
|
|
|
|
BADFILE: bad file type. Did you specify a DLL instead of an import library?
|
2018-07-14 12:07:51 +08:00
|
|
|
|
2018-07-14 19:47:23 +08:00
|
|
|
# RUN: lld-link /lib /help | FileCheck -check-prefix=LIBHELP %s
|
2021-02-15 19:30:18 +08:00
|
|
|
# RUN: lld-link -lib -help | FileCheck -check-prefix=LIBHELP %s
|
2018-07-14 12:07:51 +08:00
|
|
|
LIBHELP: OVERVIEW: LLVM Lib
|
|
|
|
|
|
[LLD][COFF] When using LLD-as-a-library, always prevent re-entrance on failures
This is a follow-up for D70378 (Cover usage of LLD as a library).
While debugging an intermittent failure on a bot, I recalled this scenario which
causes the issue:
1.When executing lld/test/ELF/invalid/symtab-sh-info.s L45, we reach
lld::elf::Obj-File::ObjFile() which goes straight into its base ELFFileBase(),
then ELFFileBase::init().
2.At that point fatal() is thrown in lld/ELF/InputFiles.cpp L381, leaving a
half-initialized ObjFile instance.
3.We then end up in lld::exitLld() and since we are running with LLD_IN_TEST, we
hapily restore the control flow to CrashRecoveryContext::RunSafely() then back
in lld::safeLldMain().
4.Before this patch, we called errorHandler().reset() just after, and this
attempted to reset the associated SpecificAlloc<ObjFile<ELF64LE>>. That tried
to free the half-initialized ObjFile instance, and more precisely its
ObjFile::dwarf member.
Sometimes that worked, sometimes it failed and was catched by the
CrashRecoveryContext. This scenario was the reason we called
errorHandler().reset() through a CrashRecoveryContext.
But in some rare cases, the above repro somehow corrupted the heap, creating a
stack overflow. When the CrashRecoveryContext's filter (that is,
__except (ExceptionFilter(GetExceptionInformation()))) tried to handle the
exception, it crashed again since the stack was exhausted -- and that took the
whole application down. That is the issue seen on the bot. Locally it happens
about 1 times out of 15.
Now this situation can happen anywhere in LLD. Since catching stack overflows is
not a reliable scenario ATM when using CrashRecoveryContext, we're now
preventing further re-entrance when such failures occur, by signaling
lld::SafeReturn::canRunAgain=false. When running with LLD_IN_TEST=2 (or above),
only one iteration will be executed, instead of two.
Differential Revision: https://reviews.llvm.org/D88348
2020-11-12 21:14:20 +08:00
|
|
|
# RUN: env LLD_IN_TEST=1 not lld-link /WX /lib 2>&1 | FileCheck -check-prefix=LIBBAD %s
|
2018-07-14 12:07:51 +08:00
|
|
|
LIBBAD: ignoring /lib since it's not the first argument
|
2019-03-12 00:30:55 +08:00
|
|
|
|
2020-08-21 06:00:25 +08:00
|
|
|
# RUN: yaml2obj %p/Inputs/hello32.yaml -o %t.obj
|
2019-03-12 00:30:55 +08:00
|
|
|
# RUN: not lld-link /out:/ %t.obj 2>&1 | FileCheck -check-prefix=DIR %s
|
|
|
|
|
DIR: cannot open output file
|
2019-05-07 21:48:30 +08:00
|
|
|
|
[LLD][COFF] When using LLD-as-a-library, always prevent re-entrance on failures
This is a follow-up for D70378 (Cover usage of LLD as a library).
While debugging an intermittent failure on a bot, I recalled this scenario which
causes the issue:
1.When executing lld/test/ELF/invalid/symtab-sh-info.s L45, we reach
lld::elf::Obj-File::ObjFile() which goes straight into its base ELFFileBase(),
then ELFFileBase::init().
2.At that point fatal() is thrown in lld/ELF/InputFiles.cpp L381, leaving a
half-initialized ObjFile instance.
3.We then end up in lld::exitLld() and since we are running with LLD_IN_TEST, we
hapily restore the control flow to CrashRecoveryContext::RunSafely() then back
in lld::safeLldMain().
4.Before this patch, we called errorHandler().reset() just after, and this
attempted to reset the associated SpecificAlloc<ObjFile<ELF64LE>>. That tried
to free the half-initialized ObjFile instance, and more precisely its
ObjFile::dwarf member.
Sometimes that worked, sometimes it failed and was catched by the
CrashRecoveryContext. This scenario was the reason we called
errorHandler().reset() through a CrashRecoveryContext.
But in some rare cases, the above repro somehow corrupted the heap, creating a
stack overflow. When the CrashRecoveryContext's filter (that is,
__except (ExceptionFilter(GetExceptionInformation()))) tried to handle the
exception, it crashed again since the stack was exhausted -- and that took the
whole application down. That is the issue seen on the bot. Locally it happens
about 1 times out of 15.
Now this situation can happen anywhere in LLD. Since catching stack overflows is
not a reliable scenario ATM when using CrashRecoveryContext, we're now
preventing further re-entrance when such failures occur, by signaling
lld::SafeReturn::canRunAgain=false. When running with LLD_IN_TEST=2 (or above),
only one iteration will be executed, instead of two.
Differential Revision: https://reviews.llvm.org/D88348
2020-11-12 21:14:20 +08:00
|
|
|
# RUN: env LLD_IN_TEST=1 not lld-link -version 2>&1 | FileCheck -check-prefix=SPELLVERSION %s
|
2019-05-07 21:48:30 +08:00
|
|
|
SPELLVERSION: ignoring unknown argument '-version', did you mean '--version'
|
|
|
|
|
SPELLVERSION: no input files
|
|
|
|
|
|
[LLD][COFF] When using LLD-as-a-library, always prevent re-entrance on failures
This is a follow-up for D70378 (Cover usage of LLD as a library).
While debugging an intermittent failure on a bot, I recalled this scenario which
causes the issue:
1.When executing lld/test/ELF/invalid/symtab-sh-info.s L45, we reach
lld::elf::Obj-File::ObjFile() which goes straight into its base ELFFileBase(),
then ELFFileBase::init().
2.At that point fatal() is thrown in lld/ELF/InputFiles.cpp L381, leaving a
half-initialized ObjFile instance.
3.We then end up in lld::exitLld() and since we are running with LLD_IN_TEST, we
hapily restore the control flow to CrashRecoveryContext::RunSafely() then back
in lld::safeLldMain().
4.Before this patch, we called errorHandler().reset() just after, and this
attempted to reset the associated SpecificAlloc<ObjFile<ELF64LE>>. That tried
to free the half-initialized ObjFile instance, and more precisely its
ObjFile::dwarf member.
Sometimes that worked, sometimes it failed and was catched by the
CrashRecoveryContext. This scenario was the reason we called
errorHandler().reset() through a CrashRecoveryContext.
But in some rare cases, the above repro somehow corrupted the heap, creating a
stack overflow. When the CrashRecoveryContext's filter (that is,
__except (ExceptionFilter(GetExceptionInformation()))) tried to handle the
exception, it crashed again since the stack was exhausted -- and that took the
whole application down. That is the issue seen on the bot. Locally it happens
about 1 times out of 15.
Now this situation can happen anywhere in LLD. Since catching stack overflows is
not a reliable scenario ATM when using CrashRecoveryContext, we're now
preventing further re-entrance when such failures occur, by signaling
lld::SafeReturn::canRunAgain=false. When running with LLD_IN_TEST=2 (or above),
only one iteration will be executed, instead of two.
Differential Revision: https://reviews.llvm.org/D88348
2020-11-12 21:14:20 +08:00
|
|
|
# RUN: env LLD_IN_TEST=1 not lld-link -nodefaultlibs 2>&1 | FileCheck -check-prefix=SPELLNODEFAULTLIB %s
|
2019-05-07 21:48:30 +08:00
|
|
|
SPELLNODEFAULTLIB: ignoring unknown argument '-nodefaultlibs', did you mean '-nodefaultlib'
|
|
|
|
|
SPELLNODEFAULTLIB: no input files
|
2019-05-24 01:58:33 +08:00
|
|
|
|
|
|
|
|
# RUN: not lld-link /nodefaultlibs 2>&1 | FileCheck -check-prefix=SPELLNODEFAULTLIB_SLASH %s
|
|
|
|
|
SPELLNODEFAULTLIB_SLASH: could not open '/nodefaultlibs': {{.*}}; did you mean '/nodefaultlib'
|
|
|
|
|
SPELLNODEFAULTLIB_SLASH-NOT: no input files
|
|
|
|
|
|
|
|
|
|
# Getting flags as typo corrections for normal input files is a side effect
|
|
|
|
|
# of how spell checking for /-style flags is implemented.
|
|
|
|
|
# RUN: not lld-link force 2>&1 | FileCheck -check-prefix=SPELLFORCE %s
|
|
|
|
|
SPELLFORCE: could not open 'force': {{.*}}; did you mean '/force'
|
|
|
|
|
SPELLFORCE-NOT: no input files
|