Implement custom sections

[bjorn3]

See https://github.com/bjorn3/rustc_codegen_cranelift/pull/435#issuecomment-477429904

This hasn't been tested with mach-O yet.

[bjorn3]

Pushed a commit to bjorn3/rustc_codegen_cranelift#435 to use this, so mach-O gets tested on travis.

[pchickey]

looks excellent!

[bjorn3]

The mach-O version might not work correctly, or I am using object wrong.

https://travis-ci.org/bjorn3/rustc_codegen_cranelift/jobs/512168839#L375

 WARN 2019-03-27T19:12:27Z: rustc_metadata::locator: no metadata found: no .rustc section

I will investigate tomorrow.

[bjorn3]

Added an objdump invocation to bjorn3/rustc_codegen_cranelift#435:

target/out/libmini_core.dylib:	file format Mach-O 64-bit x86-64
Sections:
Idx Name          Size      Address          Type
  0 __text        0000061f 0000000000000990 TEXT 
  1 __unwind_info 00000048 0000000000000fb0 DATA 
[BUILD] example
 WARN 2019-03-29T18:53:28Z: rustc_metadata::locator: no metadata found: no .rustc section
 WARN 2019-03-29T18:53:28Z: rustc_metadata::locator: no metadata found: no .rustc section

Conclusion: .rustc doesn't get emitted at all.

[philipc]

Added this code to src/bin/main.rs (might be good to include something like this in the PR):

    obj.declare(".faerie", Decl::section(SectionKind::Data))?;
    obj.define(".faerie", b"faerie".to_vec())?;

Then:

$ target/debug/prototype --mach mach
$ llvm-objdump -section-headers mach

mach:	file format Mach-O 64-bit x86-64

Sections:
Idx Name          Size      Address          Type
  0 __text        00000053 0000000000000000 TEXT 
  1 __data        0000000c 0000000000000053 DATA 
  2 __cstring     00000017 000000000000005f DATA 
  3 __faerie      00000006 0000000000000076 DATA 

[bjorn3]

It seems like the section is emitted correctly, but when linking the final dylib it is omitted. (The linker invocation seems to differ between cg_llvm and cg_clif)

[bjorn3]

might be good to include something like this in the PR)

Done

[m4b]

@bjorn3 I'm seeing the section emitted correctly on mach, along with its data "some data".

E.g.:

target/debug/prototype --deadbeef --mach deadbeef.mach.o
target/debug/prototype --mach mach.o
target/debug/prototype -l mach --mach mach.o deadbeef.mach.o

./mach
deadbeef: 0xdeadbef0 - 0xcafebabe

strings mach
deadbeef: 0x%x - 0x%x
some data

bingrep --hex mach | grep fear
00000370  00 00 00 00 00 00 00 00 5F 5F 66 61 65 72 69 65  | ........__faerie |

  Segment   # Sections  
  __DATA    4           
         Idx   Name              Addr           Size    Offset    Align   Reloff   Nrelocs   Flags  
         0     __nl_symbol_ptr   0x100001000    0x10    0x1000    3       0x0      0         0x6    
         1     __la_symbol_ptr   0x100001010    0x8     0x1010    3       0x0      0         0x7    
         2     __data            0x100001018    0x17    0x1018    3       0x0      0         0x0    
         3     __faerie          0x100001030    0x9     0x1030    1       0x0      0         0x0  

unless I'm missing something? It would be easy to add a test for this, we could emit the object file with goblin, then parse the object, check to see the data is in the section.

Anyway should we merge?

[bjorn3]

I think so. The problem with cg_clif is probably caused by different linker invocations than cg_llvm uses.

[bjorn3]

Ping @m4b

[m4b]

gosh I'm really sorry @bjorn3 merging this now...

[bjorn3]

No problem. The PR I need this for is still blocked on a rustc PR anyway.