[PATCH] D66063: [Object] Create MutableELFObject Class for Doing Mutations on ELFObjectFiles [Part 5]

Alex Brachet via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Aug 20 21:24:01 PDT 2019


abrachet marked 6 inline comments as done.
abrachet added a comment.

In D66063#1636993 <https://reviews.llvm.org/D66063#1636993>, @jhenderson wrote:

> I've been trying and failing to come up with a good solution to the design. I only see three options:
>
> 1. Adding the getHeader function as this patch does and accepting some fragility. In practice, usages within LLVM are probably fine, because we'll have testing, but it might not work as well for those who wish to use the library in their own tools.
> 2. Using private inheritance or making the ELFObjectFile a private member of MutableELFObject instead of a base class. This would require MutableELFObject to opt in into functions that we know to be safe to use, and wouldn't allow usage of other functions. This is safer, but could result in a fair amount of extra code. This might need to be combined with 1) too to fix the specific issues this patch addresses.
> 3. Something more radical involving bigger changes in ELFObjectFile to prevent accessing the wrong header within the base class. I don't have anything specific in mind here at the moment.
>
>   Does anybody else have any thoughts on this?


I'll wait to see if anyone else chimes in before working on this


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D66063/new/

https://reviews.llvm.org/D66063





More information about the llvm-commits mailing list