[PATCH] D44702: [llvm-objcopy] Keep the information about the object elf type

Jake Ehrlich via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Mar 20 17:16:43 PDT 2018


jakehehrlich added a comment.

In https://reviews.llvm.org/D44702#1043931, @alexshap wrote:

> @jakehehrlich, sorry, but i have to disagree with this. As i said before,  initializeSymbol, initializeRelocations are essentially harmful, they break the encapsulation and the separation of concerns,
>  killing "initialize" in Section* types would make them classes without responsibility (which should not exist) + i would anticipate this would make the issue with duplication even worse 
>  (because the internals of particular types of sections are tightly related to how they evolve when smth changes are how they are initialized at the first place).  Could you please clarify why you think that ELFtype is not a part of the object, but all the other flags  uint32_t Type; uint32_t Machine; uint32_t Version etc are ? maybe @jhenderson can weigh in. also I assume I might be missing smth.


It's my vision that the section types and object essentially be data and that they not be coupled to how they're read in or how they're written out. I was bitten by coupling those things already and I don't want to go backwards on that issue. Type, Machine, and Version all have no effect on how the final object is output. A valid complaint is however that Ident *does* have something to do with how the final data is written out. I want that to be constructed by the Writer for that reason. I agree that initializeSymbol and initalizeRelocation are bad. I'm not sure what issues with duplication you're specifically mentioning or what would be made worse by this though. Could you clarify?


Repository:
  rL LLVM

https://reviews.llvm.org/D44702





More information about the llvm-commits mailing list