[PATCH] D59945: [ObjCMetadata] Add support for reading Objective-C metadata

Steven Wu via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Apr 1 09:54:01 PDT 2019


steven_wu added a comment.

In D59945#1449696 <https://reviews.llvm.org/D59945#1449696>, @theraven wrote:

> I am not convinced that there is sufficient abstraction here to handle multiple runtimes without significant code duplication. The Mach-O and LLVM IR parsers both appear to duplicate all knowledge of the runtime's data structures, so if you wanted to add a second runtime you'd then need four classes.  I would expect to see two abstraction layers:
>
> 1. Something allowing you to specify a data structure to examine that would load it from some binary (IR, Mach-O, ELF, whatever).
> 2. Something built on top of this that then queries specific runtime metadata structures.
>
>   In clang, we support two broad families of Objective-C runtime: Apple (Legacy and Modern, with version-specific things for macOS, iOS, and so on) and GNU (including GCC, GNUstep / WinObjC, and ObjFW).  These are largely orthogonal to object file formats.  For example, the GNUstep runtime is widely used with both ELF and PE/COFF binaries and can be used with Mach-O (though typically only for testing).  If we wanted to add support for all of these, I suspect that we'd have a code explosion.


I understand the concern. When I say the library has the abstraction to support multiple runtime and object file format in RFC, I was talking about the interface of the metadata reader. The design choice is not to expose runtime data structure to the library interfaces so there can be a unified interface no matter what the actual object file and runtime is used. The prototype has implemented Apple (both legacy and modern) with Macho and LLVM bitcode object file format. With how different the data structures really are, that aren't much sharing between implementations. There is potential to add another layer of abstraction of object file format underneath to eliminate some boiler plates (and those should probably add to libObject directly). If you have better idea and design, please let me know.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D59945





More information about the llvm-commits mailing list