[PATCH] D33964: [LLVM][llvm-objcopy] Added basic plumbing to get things started

[Michael Spencer via llvm-commits]

On Thu, Jun 15, 2017 at 12:31 PM, Jake Ehrlich via Phabricator <
reviews at reviews.llvm.org> wrote:

> jakehehrlich marked 14 inline comments as done.
> jakehehrlich added a comment.
>
> In https://reviews.llvm.org/D33964#781402, @meadori wrote:
>
> > I having looked through the fine details yet, but one higher level
> question: I saw the discussions on the mailing list concerning being
> careful not to go overboard making everything work with multiple object
> file formats and to start with ELF.  That being said, why can't just the
> ELF functionality of libObject be extended to write?  Seems like going that
> way would make it easier for others to reuse in other tools.
>
>
> As I understand it libObject reads in the file to memory and then simply
> reinterpret_casts the different chunks of the file into the corresponding
> parts. So when you get an Elf64_Shdr* from the libObject interface you
> actually are getting a pointer into the file data. It's sort of like
> "in-place" file parsing. It might even be memory mapping the file, I'm not
> sure. My point is that It does not have it's own internal modifiable
> representation of the file. It just has the raw data from the file.
> Changing the interface to include section/symbol removal (which involves
> changing file layout and modifying sections like .shstrtab and .shtab)
> would cause the internal workings of libObject to change a lot I think.
> Perhaps someone can confirm my understanding?
>

Correct. libObject directly references memory mapped files. Extending
libObject to write files is a huge effort that hasn't proven to be worth
the effort over the current approach.

- Michael Spencer


>
>
> Repository:
>   rL LLVM
>
> https://reviews.llvm.org/D33964
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170615/084a1e4f/attachment.html>