llvm-project/lld/test/COFF/invalid-obj.test

# RUN: yaml2obj %s -o %t.obj
# RUN: env LLD_IN_TEST=1 not lld-link %t.obj 2>&1 | FileCheck %s

# CHECK: getSectionName failed: #1:

--- !COFF
header:
  Machine:         IMAGE_FILE_MACHINE_AMD64
  Characteristics: []
sections:
  - Name:            '/1'
    Characteristics: []
    SectionData:     00
symbols:
[test] Replace `yaml2obj >` with `yaml2obj -o` and remove unneeded input redirection 2020-08-21 06:00:25 +08:00			`# RUN: yaml2obj %s -o %t.obj`
[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 %t.obj 2>&1 \| FileCheck %s`
COFF: Corrected error message if a section failed to load. There is no sense to use Name in these lines as it is not initialized yet. Patch from Igor Kudrin! llvm-svn: 247531 2015-09-14 04:22:22 +08:00
			`# CHECK: getSectionName failed: #1:`

[yaml2obj] Updating LLD tests to account for LLVM r273915 This removed the -format flag from yaml2obj in favor of YAML tags. llvm-svn: 273920 2016-06-28 04:17:08 +08:00			`--- !COFF`
COFF: Corrected error message if a section failed to load. There is no sense to use Name in these lines as it is not initialized yet. Patch from Igor Kudrin! llvm-svn: 247531 2015-09-14 04:22:22 +08:00			`header:`
			`Machine: IMAGE_FILE_MACHINE_AMD64`
			`Characteristics: []`
			`sections:`
			`- Name: '/1'`
			`Characteristics: []`
			`SectionData: 00`
			`symbols:`