[llvm-bugs] [Bug 36515] New: Regression when empty script sections have explict address
via llvm-bugs
llvm-bugs at lists.llvm.org
Mon Feb 26 04:41:08 PST 2018
https://bugs.llvm.org/show_bug.cgi?id=36515
Bug ID: 36515
Summary: Regression when empty script sections have explict
address
Product: lld
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: release blocker
Priority: P
Component: ELF
Assignee: unassignedbugs at nondot.org
Reporter: jh7370.2008 at my.bristol.ac.uk
CC: llvm-bugs at lists.llvm.org
This bug is a regression caused by r325887. Consider the following script and
assembly file:
// test.script
PHDRS
{
ph_headers PT_PHDR PHDRS;
ph_text PT_LOAD FILEHDR PHDRS FLAGS (0x1 | 0x4);
}
SECTIONS
{
. = 0xffffffff20000000 + SIZEOF_HEADERS;
.text : { *(.text*) } : ph_text
.debug_info 0 : { *(.debug_info) }
}
// test.s
.text
.globl _start
_start:
nop
Previous to the above revision, LLD would happily link this case, and discard
.debug_info, since it was empty. However, now it attempts to assign .debug_info
an address of zero, and keeps it because of the change made. The exact result
depends on the system I tested it on. On Windows I got the following error:
C:\Work\TempWork> C:\llvm\build\Debug\bin\ld.lld.exe test.o -o test.elf -T
.\test.script
C:\llvm\build\Debug\bin\ld.lld.exe: error: failed to open test.elf: The
requested operation cannot be performed on a file with a user-mapped section
open.
On Linux, I get a segmentation fault. I haven't debugged the Linux failure, but
I assume that it has the same cause (note - I was using a slightly different
revision of LLD for this):
#0 0x00000000004326dd llvm::sys::PrintStackTrace(llvm::raw_ostream&)
/home/binutils/llvm/llvm/lib/Support/Unix/Signals.inc:398:0
#1 0x000000000043276e PrintStackTraceSignalHandler(void*)
/home/binutils/llvm/llvm/lib/Support/Unix/Signals.inc:462:0
#2 0x0000000000430b56 llvm::sys::RunSignalHandlers()
/home/binutils/llvm/llvm/lib/Support/Signals.cpp:49:0
#3 0x0000000000432075 SignalHandler(int)
/home/binutils/llvm/llvm/lib/Support/Unix/Signals.inc:252:0
#4 0x00007fd1dd2b4330 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x10330)
#5 0x00007fd1dc313bf4
/build/eglibc-SvCtMH/eglibc-2.19/string/../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:142:0
#6 0x0000000000600a03 void
lld::elf::InputSection::writeTo<llvm::object::ELFType<(llvm::support::endianness)1,
true> >(unsigned char*)
/home/binutils/llvm/llvm/tools/lld/ELF/InputSection.cpp:784:0
#7 0x000000000062def6 void
lld::elf::OutputSection::writeTo<llvm::object::ELFType<(llvm::support::endianness)1,
true> >(unsigned char*)::{lambda(unsigned long)#1}::operator()(unsigned long)
const /home/binutils/llvm/llvm/tools/lld/ELF/OutputSections.cpp:244:0
#8 0x000000000062def6 void
lld::elf::OutputSection::writeTo<llvm::object::ELFType<(llvm::support::endianness)1,
true> >(unsigned char*)::{lambda(unsigned long)#1}::operator()(unsigned long)
const (../llvm/build/bin/ld.lld+0x62def6)
#9 0x0000000000631f3c std::_Function_handler<void (unsigned long), void
lld::elf::OutputSection::writeTo<llvm::object::ELFType<(llvm::support::endianness)1,
true> >(unsigned char*)::{lambda(unsigned long)#1}>::_M_invoke(std::_Any_data
const&, unsigned long) /usr/include/c++/4.8/functional:2073:0
#10 0x00000000005af253 std::function<void (unsigned long)>::operator()(unsigned
long) const /usr/include/c++/4.8/functional:2472:0
#11 0x00000000005af1d0 void
llvm::parallel::detail::parallel_for_each_n<unsigned long, std::function<void
(unsigned long)> >(unsigned long, unsigned long, std::function<void (unsigned
long)>) /home/binutils/llvm/llvm/include/llvm/Support/Parallel.h:182:0
#12 0x00000000005aee07 void llvm::parallel::for_each_n<unsigned long,
std::function<void (unsigned long)>
>(llvm::parallel::parallel_execution_policy, unsigned long, unsigned long,
std::function<void (unsigned long)>)
/home/binutils/llvm/llvm/include/llvm/Support/Parallel.h:240:0
#13 0x00000000005aecbe lld::parallelForEachN(unsigned long, unsigned long,
std::function<void (unsigned long)>)
/home/binutils/llvm/llvm/tools/lld/include/lld/Common/Threads.h:79:0
#14 0x000000000062e257 void
lld::elf::OutputSection::writeTo<llvm::object::ELFType<(llvm::support::endianness)1,
true> >(unsigned char*)
/home/binutils/llvm/llvm/tools/lld/ELF/OutputSections.cpp:253:0
#15 0x00000000006e356e (anonymous
namespace)::Writer<llvm::object::ELFType<(llvm::support::endianness)1, true>
>::writeSections() /home/binutils/llvm/llvm/tools/lld/ELF/Writer.cpp:2215:0
#16 0x00000000006d812a (anonymous
namespace)::Writer<llvm::object::ELFType<(llvm::support::endianness)1, true>
>::run() /home/binutils/llvm/llvm/tools/lld/ELF/Writer.cpp:467:0
#17 0x000000000070bbb8 void
lld::elf::writeResult<llvm::object::ELFType<(llvm::support::endianness)1, true>
>() /home/binutils/llvm/llvm/tools/lld/ELF/Writer.cpp:128:0
#18 0x000000000058d664 void
lld::elf::LinkerDriver::link<llvm::object::ELFType<(llvm::support::endianness)1,
true> >(llvm::opt::InputArgList&)
/home/binutils/llvm/llvm/tools/lld/ELF/Driver.cpp:1174:0
#19 0x000000000057e39f lld::elf::LinkerDriver::main(llvm::ArrayRef<char
const*>) /home/binutils/llvm/llvm/tools/lld/ELF/Driver.cpp:387:0
#20 0x000000000057b665 lld::elf::link(llvm::ArrayRef<char const*>, bool,
llvm::raw_ostream&) /home/binutils/llvm/llvm/tools/lld/ELF/Driver.cpp:103:0
#21 0x000000000040a03b main
/home/binutils/llvm/llvm/tools/lld/tools/lld/lld.cpp:127:0
#22 0x00007fd1dc29af45 __libc_start_main
/build/eglibc-SvCtMH/eglibc-2.19/csu/libc-start.c:321:0
#23 0x0000000000408619 _start (../llvm/build/bin/ld.lld+0x408619)
Stack dump:
0. Program arguments: ../llvm/build/bin/ld.lld test.o -o test.elf -T
test.script
Segmentation fault (core dumped)
I don't think the approach taken in r325887 was the correct method for solving
the problem it was trying to solve - sections with these descriptions should
still not be in the output, and should not contribute to address assignments
etc. Note that bfd does not have any issues with this test case and does not
emit the .debug_info section in the output.
--
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/20180226/86ec87d7/attachment.html>
More information about the llvm-bugs
mailing list