Consider providing an universal way to read (proc macro) dylib metadata.

[eddyb]

In EmbarkStudios/rust-gpu#268, I used rustc_codegen_llvm's implementation of get_dylib_metadata, in order to support proc macros, and also found out that rustc_codegen_cranelift uses the object crate for its get_dylib_metadata.
(Both the LLVM and the object-based implementation extract the .rustc section of an .so, .dll, etc.)

AFAICT, the codegen backend shouldn't really matter, for proc macros specifically, as the proc macro is compiled for the same ("host") platform executing rustc, and for which we have dlopen (or equivalent) support.

So if we trust the object crate to work for at least proc macros, we can attempt to access the dylib metadata using it (i.e. just like rustc_codegen_cranelift does), before we ask the codegen backend for a fallback implementation (which could specifically handle non-proc-macro target dylib crates).

cc @bjorn3 @khyperia @nagisa

[bjorn3]

I think that for proc macros the universal way to read should be the only way used. For regular dylibs, I think the metadata loader from the codegen backend should still always be used, but the default implementation of get_dylib_metadata should delegate to the universal way. This would allow the codegen backend to store dylib metadata in a way that is incompatible with the universal way without overhead from first trying the universal way.