[llvm-bugs] [Bug 42890] New: LLD crashes on partial discard of .ARM.exidx sections

via llvm-bugs llvm-bugs at lists.llvm.org
Mon Aug 5 07:24:06 PDT 2019


https://bugs.llvm.org/show_bug.cgi?id=42890

            Bug ID: 42890
           Summary: LLD crashes on partial discard of .ARM.exidx sections
           Product: lld
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: ELF
          Assignee: unassignedbugs at nondot.org
          Reporter: peter.smith at linaro.org
                CC: llvm-bugs at lists.llvm.org, peter.smith at linaro.org

Cut down reproducer for: https://github.com/ClangBuiltLinux/linux/issues/626

When the .ARM.exidx sections are partially but not totally discarded LLD
crashes. It is highly likely that a partial discard is user-error [*], but LLD
should be robust against this.

cat t1.s
        .section .exit.text, "ax", %progbits
        .globl foo
        .type foo, %function
foo:    
        .fnstart        
        bx lr
        .cantunwind
        .fnend

cat t2.s
        .text
        .globl _start
        .type _start, %function
_start:
        .fnstart        
        bx lr
        .cantunwind
        .fnend

cat t.lds
SECTIONS
{
 /DISCARD/ : { *(.exit.text) }
}

clang -c --target=armv7a-linux-gnu t.s t2.s
ld.lld t.o t2.o -T t.lds
Stack dump:
0.      Program arguments: bin/ld.lld t.o t2.o -o t.axf -T t.lds 
 #0 0x000000000049fab4 PrintStackTraceSignalHandler(void*)
(bin/ld.lld+0x49fab4)
 #1 0x000000000049d680 llvm::sys::RunSignalHandlers() (bin/ld.lld+0x49d680)
 #2 0x00000000004a0048 SignalHandler(int) (bin/ld.lld+0x4a0048)
 #3 0x00007f2d200b0390 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x11390)
 #4 0x00000000006d9eef void
std::__merge_adaptive<__gnu_cxx::__normal_iterator<lld::elf::InputSection**,
std::vector<lld::elf::InputSection*, std::allocator<lld::elf::InputSection*> >
>, long, lld::elf::InputSection**,
__gnu_cxx::__ops::_Iter_comp_iter<lld::elf::ARMExidxSyntheticSection::finalizeContents()::$_18>
>(__gnu_cxx::__normal_iterator<lld::elf::InputSection**,
std::vector<lld::elf::InputSection*, std::allocator<lld::elf::InputSection*> >
>, __gnu_cxx::__normal_iterator<lld::elf::InputSection**,
std::vector<lld::elf::InputSection*, std::allocator<lld::elf::InputSection*> >
>, __gnu_cxx::__normal_iterator<lld::elf::InputSection**,
std::vector<lld::elf::InputSection*, std::allocator<lld::elf::InputSection*> >
>, long, long, lld::elf::InputSection**, long,
__gnu_cxx::__ops::_Iter_comp_iter<lld::elf::ARMExidxSyntheticSection::finalizeContents()::$_18>)
(bin/ld.lld+0x6d9eef)
...

[*] A partial discard does not make a lot of sense as the way that the table is
defined (PC range of entry N is terminated by start of entry N + 1) means that
a partial table is potentially dangerous and the linker must already fill in
the gaps. The only use case I can see is for a discard of table entries with
unwinding info so that the linker can regenerate cantunwind tables but this
does not seem likely. 

I think that there are 3 alternatives to resolve this:
1.) A partial discard is treated as a total discard.
2.) A partial discard suppresses linker generation of missing table entries.
3.) The linker recreates the discarded table entries.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20190805/a594d5ac/attachment-0001.html>


More information about the llvm-bugs mailing list