Read and write dylib metadata

[bjorn3]

@m4b I (mis)used Decl::debug_section() to add a .rustc section. Is this supported or may future versions of faerie break this?

Fixes #412

[bjorn3]

I used it here.

[philipc]

For MachO, Decl::debug_section() is placed in the __DWARF segment.

[m4b]

Yea we need to add explicit section ability, it’s unfortunately not implemented yet to my knowledge. I don’t think it will be a lot of work since we already write out sections so the machinery is there. Someone just needs to add the api :)

@bjorn3 would you like to try out a PR? :D

[bjorn3]

For MachO, Decl::debug_section() is placed in the __DWARF segment.

cg_llvm puts it in __DATA. :) It also explains the macOS travis failure.

@bjorn3 would you like to try out a PR? :D

Sure

[bjorn3]

Blocked on rust-lang/rust#59564 to stop the duplication of the linker code between cg_clif and cg_llvm.

[bjorn3]

The .rustc section is somehow discarded when linking the metadata module into the dylib on macOS. @m4b do you have any clue how that could be?

[bjorn3]

Seems like there should be a symbol names like _rust_metadata_rust_out_8787f43e282added376259c1adb08b80 in the .rustc section:

https://github.com/rust-lang/rust/blob/767f59462663fbc55a69d39fc5e1f7f83b6fb37d/src/librustc_codegen_llvm/base.rs#L61

[m4b]

@bjorn3 Sorry missed your ping, did your recent PR to faerie resolve the issue about dylibs having sections discarded ?

[bjorn3]

Sorry missed your ping

No problem.

did your recent PR to faerie resolve the issue about dylibs having sections discarded ?

No, cg_llvm seems to also create a symbol referencing the metadata. Doing that here too may solve the problem. Unfortunately faerie doesnt support symbols in custom sections.

[m4b]

Hmm, I thought you could create a symbol referencing a section; @pchickey any suggestion here?
In the meantime, @bjorn3 could you just add a manual line in faerie creating the symbol referencing your section metadata to confirm it's the issue?

[bjorn3]

Yup adding a global symbol pointing to the start of the section fixes it:

Sections:
Idx Name          Size      Address          Type
  0 __text        00000679 0000000000000910 TEXT 
  1 __stubs       00000006 0000000000000f8a TEXT 
  2 __stub_helper 0000001a 0000000000000f90 TEXT 
  3 __unwind_info 00000048 0000000000000fac DATA 
  4 __nl_symbol_ptr 00000010 0000000000001000 DATA 
  5 __la_symbol_ptr 00000008 0000000000001010 DATA 
  6 __data        00000541 0000000000001018 DATA 
  7 .rustc        0000491d 000000000000155a DATA 

[bjorn3]

In what way should faerie expose this? Specify the section a normal decl is put in? Or specify the symbols for a section decl?

[bjorn3]

Gentle ping @m4b

[m4b]

@bjorn3 given your results, it seems reasonable for the user to specify symbol + data + optional section, and create the section if it isn’t there ? I suspect it’s going to complicate some of the setup logic, but maybe not.

Will require another PR :( is this blocking you right now ?

[bjorn3]

Did you see m4b/faerie#83? I chose the "Specify the symbols for a section decl?" route. This is not really blocking me.

[bjorn3]

This has a patch section, because m4b/faerie#83 and gimli-rs/object#109 haven't landed in a version published on crates.io.