[llvm-bugs] [Bug 42145] New: Make llvm-objcopy preserve instruction padding in binaries created by lld

[via llvm-bugs]

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

            Bug ID: 42145
           Summary: Make llvm-objcopy preserve instruction padding in
                    binaries created by lld
           Product: tools
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: llvm-objcopy/strip
          Assignee: unassignedbugs at nondot.org
          Reporter: peter at pcc.me.uk
                CC: alexander.v.shaposhnikov at gmail.com,
                    jake.h.ehrlich at gmail.com,
                    jh7370.2008 at my.bristol.ac.uk,
                    llvm-bugs at lists.llvm.org, rupprecht at google.com

As of https://reviews.llvm.org/D59483 llvm-objcopy preserves data in segments
but outside of sections. However, this is not always enough to cause
llvm-objcopy to preserve the instruction padding created by lld [1] because lld
will only adjust p_filesz/p_memsz for executable segments to cover padding if
they are the last segment in the file.

We could change lld to adjust p_filesz/p_memsz for all executable segments to
cover padding, not just the last one. This will cause llvm-objcopy to preserve
padding, but I see two problems with it:

1) This isn't enough to cause GNU strip/objcopy and eu-strip to preserve
padding. It looks like they look at the segment's sections and not
p_filesz/p_memsz in order to determine how much of the segment to copy.

2) With an adjusted p_filesz/p_memsz, GNU strip/objcopy and eu-strip will both
adjust p_filesz/p_memsz back to cover only the sections. This means that gdb's
logic [2] for matching core dumps against binaries will break since it will
expect the segment's p_filesz/p_memsz fields to match between the core dump
(which has the stripped file's segments) and the binary (which has the
unstripped file's segments). Arguably we could be hitting this issue right now
because of lld's current rounding up behaviour but because binaries whose last
segment is executable aren't very common (normally there will be a data, relro
or bss segment after it) I'd expect users to start hitting this issue more
frequently.

Here are a couple of other possible solutions:

1) Change lld to create dummy sections at the end of each segment that contain
the instruction padding. This should fix all of GNU strip/objcopy, eu-strip and
llvm-strip/llvm-objcopy and shouldn't cause problems with gdb.

2) Teach llvm-objcopy to round up p_filesz/p_memsz to the address of either the
next segment or the next non-segment section when copying section data. This
will solve the problem for llvm-objcopy/llvm-strip but not any other strip
tools.

[1] http://llvm-cs.pcc.me.uk/tools/lld/ELF/Writer.cpp#2489
[2]
https://github.com/bminor/binutils-gdb/blob/fbe4d6650d714643fe340d9ccba7fc500c26b91d/gdb/solib-svr4.c#L2585

-- 
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/20190605/e5142e8b/attachment.html>