[llvm-dev] llvm-objcopy proposal

Tue Jun 6 16:34:31 PDT 2017

On Tue, Jun 6, 2017 at 4:03 PM, Jake Ehrlich via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Fantastic! Thanks for all of the input! I'll be considering all of it
> going forward. The plan right now is just to worry about ELF executables
> and nothing else. I'm very sympathetic to the "llvm-objtool" change. If
> everyone is cool with it I'll change the name in the next CL to
> "llvm-objtool".
>
> To start out I implemented a very basic ELF64LE specific bit of code. I'm
> currently looking for reviewers on it. The phabricator link is here:
> https://reviews.llvm.org/D33964. I'd like to find people willing to
> review this as I work on this going forward as well. I haven't bothered
> worrying about it but I imagine that this will template fairly easily to
> support ELF32LE, ELF32BE, and ELF64BE.
>
> Would anyone be willing to let me set them as a reviewer going forward for
> future CLs?
>

Please add me as a reviewer.

- Michael Spencer

>
> On Sun, Jun 4, 2017 at 6:07 PM Sean Silva via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> On Fri, Jun 2, 2017 at 3:52 PM, James Y Knight via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>>
>>>
>>> On Fri, Jun 2, 2017 at 2:34 PM, Ed Maste via llvm-dev <
>>> llvm-dev at lists.llvm.org> wrote:
>>>
>>>> One additional use case for you: converting from a binary to an ELF
>>>> object file
>>>> ```
>>>> objcopy -I binary -O elf64-x86-64 foo.bin foo.o
>>>> ```
>>>> This is sometimes used for embedding binary files for use by drivers
>>>> and such.
>>>>
>>>
>>> Yea, unfortunately the command-line you actually end up needing is more
>>> like:
>>>   objcopy -I binary -Bi386:x86-64 -Oelf64-x86-64 --rename-section
>>> .data=.rodata,alloc,load,readonly,data,contents --add-section
>>> .note.GNU-stack=/dev/null
>>>
>>> Having to manually invoke objcopy and know what to specify for the -B
>>> and -O options, and to know you need the .note.GNU-stack section, and how
>>> to move it into rodata...it's really all quite terrible. Nobody should have
>>> to do that. :(
>>>
>>> There's also the "-b binary" flag to GNU ld (both bfd and gold). But,
>>> you typically need to do a dedicated "link" for that. You do:
>>>   ld -r -b binary picture.jpg -o foo.o
>>> How does ld know what output format to use here? It's gotta just choose
>>> the default, which is kinda poor...or the user needs to know how to spell
>>> an "emulation" and output format...
>>>
>>
>> One way to hack around this might be to pass in one of the other object
>> files in your project, and have the output .o file replace it. Still pretty
>> hacky and brittle (and hard to integrate into a build system I would think).
>>
>>
>>>
>>> You could imagine trying to use -Wl to put it with the compile command,
>>> but what do you use to switch back to the normal object format?
>>>   gcc main.c -Wl,-b -Wl,binary -Wl,picture.jpg -Wl,-b -Wl,<<something to
>>> undo binary mode?>>
>>>
>>> So, anyways, while this is _possible_ with objcopy, it'd sure be nice if
>>> you never needed to use it for that...
>>>
>>
>> The other approaches I've seen or can imagine are:
>>
>> - Assembler `.incbin` directive (could use it from an inline asm).
>> - Use a "bin2h" type program which takes a binary and spits out a C file
>> with a giant uint8_t[] literal in it, then include that in one of your
>> normal .c files. In theory a C++11 raw string literal could bypass most of
>> the parsing overhead of a big array literal, but the people that care about
>> including a binary in their program probably don't care about that.
>>
>> -- Sean Silva
>>
>>
>>>
>>> (BTW, Apple ld actually has an option "-sectcreate SEGNAME SECTNAME
>>> INPUT_FILE", and the clang driver will pass it through to the linker.)
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170606/d4e7e5d6/attachment.html>