New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Invalid section names in Mach-O file on OS X w/ custom target spec #22915

Closed
alexchandel opened this Issue Mar 1, 2015 · 8 comments

Comments

Projects
None yet
8 participants
@alexchandel

alexchandel commented Mar 1, 2015

Despite a valid target specification for i686-unknown-plan9, which is intended to produce a statically linked Mach-O,

{
    "pre-link-args": ["-static"],
    "data-layout": "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:8-s0:32:32-f80:128:128-n8:16:32:64-S0",
    "llvm-target": "i686-apple-darwin",
    "target-endian": "little",
    "target-pointer-width": "32",
    "arch": "x86",
    "os": "plan9",
    "morestack": false,
    "dynamic_linking": false,
    "executables": true,
    "is_like_osx": true
}

I cannot even build libcore because rustc still tries to produce a Mach-O with invalid, ELF-like section names:

rustc --target i686-unknown-plan9 -O -Z no-landing-pads -C no-stack-check --out-dir target/i686-unknown-plan9 libcore/lib.rs
LLVM ERROR: Global variable 'rust_metadata_core_89ea4c7b067f3bc4' has an invalid section specifier '.note.rustc': mach-o section specifier requires a segment and section separated by a comma.
make: *** [target/i686-unknown-plan9/libcore.rlib] Error 1
@huonw

This comment has been minimized.

Show comment
Hide comment
@huonw

huonw Mar 1, 2015

Member

So, to be clear, the problem here is specifically that rustc generates invalid data for creating mach-o object files?

Member

huonw commented Mar 1, 2015

So, to be clear, the problem here is specifically that rustc generates invalid data for creating mach-o object files?

@nagisa

This comment has been minimized.

Show comment
Hide comment
@nagisa

nagisa Mar 1, 2015

Contributor

Interesting. This call to get_metadata_section is the relevant code.

Contributor

nagisa commented Mar 1, 2015

Interesting. This call to get_metadata_section is the relevant code.

@alexchandel

This comment has been minimized.

Show comment
Hide comment
@alexchandel

alexchandel Mar 1, 2015

@huonw I think so, but I'm not sure where the section names (and segment names in Mach-O) get emitted. I intended "llvm-target": "i686-apple-darwin" and "is_like_osx": true to cause rustc to produce a Mach-O. Is the object format determined by rustc or by LLVM?

alexchandel commented Mar 1, 2015

@huonw I think so, but I'm not sure where the section names (and segment names in Mach-O) get emitted. I intended "llvm-target": "i686-apple-darwin" and "is_like_osx": true to cause rustc to produce a Mach-O. Is the object format determined by rustc or by LLVM?

@kmcallister kmcallister changed the title from Target specification isn't specific enough on OS X. to Invalid section names in Mach-O file on OS X w/ custom target spec Mar 2, 2015

@steveklabnik

This comment has been minimized.

Show comment
Hide comment
@steveklabnik

steveklabnik May 24, 2016

Member

Triage: no changes I'm aware of

Member

steveklabnik commented May 24, 2016

Triage: no changes I'm aware of

@alexchandel

This comment has been minimized.

Show comment
Hide comment
@alexchandel

alexchandel Jun 1, 2016

Presently, the compiler dies with the error

Assertion failed: (TM.isCompatibleDataLayout(getDataLayout()) && "Can't create a MachineFunction using a Module with a " "Target-incompatible DataLayout attached\n"), function MachineFunction, file /Users/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-mac/build/src/llvm/lib/CodeGen/MachineFunction.cpp, line 108.

when given a json for i686-unknown-plan9 with "data-layout": "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-f32:32:32-a:0:8-n8:16:32-S0". This error happens even when the "data-layout" is reduced to just "e-p:32:32:32" though.

Leaving the field out altogether triggers this error:

error: internal compiler error: unexpected panic
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports
thread 'rustc' panicked at 'Field data-layout in target specification is required', ../src/librustc_back/target/mod.rs:377

So it's unknown whether ELF sections are still produced, since those would be linker errors.

alexchandel commented Jun 1, 2016

Presently, the compiler dies with the error

Assertion failed: (TM.isCompatibleDataLayout(getDataLayout()) && "Can't create a MachineFunction using a Module with a " "Target-incompatible DataLayout attached\n"), function MachineFunction, file /Users/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-mac/build/src/llvm/lib/CodeGen/MachineFunction.cpp, line 108.

when given a json for i686-unknown-plan9 with "data-layout": "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-f32:32:32-a:0:8-n8:16:32-S0". This error happens even when the "data-layout" is reduced to just "e-p:32:32:32" though.

Leaving the field out altogether triggers this error:

error: internal compiler error: unexpected panic
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports
thread 'rustc' panicked at 'Field data-layout in target specification is required', ../src/librustc_back/target/mod.rs:377

So it's unknown whether ELF sections are still produced, since those would be linker errors.

frewsxcv added a commit to rust-fuzz/afl.rs that referenced this issue Nov 12, 2017

Rewerite of afl.rs; introduction of cargo-afl.
Before
======

AFL is a coverage guided fuzzer. Prior to these changes, afl.rs
would rely on [an LLVM pass] to instrument the fuzz target and get
insight into the code branches hit by the fuzzer.

Depending on the user's system, sometimes the ABI stars would align and
this would work. But [seemingly most of the time][problems], it was a
headache for many users.

[an LLVM pass]: https://github.com/rust-fuzz/afl.rs/tree/6d5b5256d7a9a4909a00ba86501be7c9687cd56e/afl-plugin
[problems]: #57

After
====

With these changes, the LLVM pass is no longer necessary. Instead of
using AFL's own LLVM pass for instrumentation, this pull request
migrates to LLVM's built-in execution tracing feature
`trace-pc-guard` which [AFL supports].

Effectively, these changes makes fuzzing Rust code with AFL _much_
easier than before. In particular:

- No longer requires unstable Rust features
- Works on all Rust channels (stable, beta, nightly)
- No longer need to modify the Rust crate being fuzzed, just write the
  fuzz target
- Linux-only for now, but if [this Rust bug] gets fixed, it'll work on macOS

[AFL supports]: https://github.com/mirrorer/afl/blob/2fb5a3482ec27b593c57258baae7089ebdc89043/llvm_mode/README.llvm#L169-L188
[this Rust bug]: rust-lang/rust#22915

frewsxcv added a commit to rust-fuzz/afl.rs that referenced this issue Nov 12, 2017

Rewerite of afl.rs; introduction of cargo-afl.
Before
======

AFL is a coverage guided fuzzer. Prior to these changes, afl.rs
would rely on [an LLVM pass] to instrument the fuzz target and get
insight into the code branches hit by the fuzzer.

Depending on the user's system, sometimes the ABI stars would align and
this would work. But [seemingly most of the time][problems], it was a
headache for many users.

[an LLVM pass]: https://github.com/rust-fuzz/afl.rs/tree/6d5b5256d7a9a4909a00ba86501be7c9687cd56e/afl-plugin
[problems]: #57

After
====

With these changes, the LLVM pass is no longer necessary. Instead of
using AFL's own LLVM pass for instrumentation, this pull request
migrates to LLVM's built-in execution tracing feature
`trace-pc-guard` which [AFL supports].

Effectively, these changes makes fuzzing Rust code with AFL _much_
easier than before. In particular:

- No longer requires unstable Rust features
- Works on all Rust channels (stable, beta, nightly)
- No longer need to modify the Rust crate being fuzzed, just write the
  fuzz target
- Linux-only for now, but if [this Rust bug] gets fixed, it'll work on macOS

[AFL supports]: https://github.com/mirrorer/afl/blob/2fb5a3482ec27b593c57258baae7089ebdc89043/llvm_mode/README.llvm#L169-L188
[this Rust bug]: rust-lang/rust#22915

frewsxcv added a commit to rust-fuzz/afl.rs that referenced this issue Nov 12, 2017

Rewerite of afl.rs; introduction of cargo-afl.
Before
======

AFL is a coverage guided fuzzer. Prior to these changes, afl.rs
would rely on [an LLVM pass] to instrument the fuzz target and get
insight into the code branches hit by the fuzzer.

Depending on the user's system, sometimes the ABI stars would align and
this would work. But [seemingly most of the time][problems], it was a
headache for many users.

[an LLVM pass]: https://github.com/rust-fuzz/afl.rs/tree/6d5b5256d7a9a4909a00ba86501be7c9687cd56e/afl-plugin
[problems]: #57

After
====

With these changes, the LLVM pass is no longer necessary. Instead of
using AFL's own LLVM pass for instrumentation, this pull request
migrates to LLVM's built-in execution tracing feature
`trace-pc-guard` which [AFL supports].

Effectively, these changes makes fuzzing Rust code with AFL _much_
easier than before. In particular:

- No longer requires unstable Rust features
- Works on all Rust channels (stable, beta, nightly)
- No longer need to modify the Rust crate being fuzzed, just write the
  fuzz target
- Linux-only for now, but if [this Rust bug] gets fixed, it'll work on macOS

[AFL supports]: https://github.com/mirrorer/afl/blob/2fb5a3482ec27b593c57258baae7089ebdc89043/llvm_mode/README.llvm#L169-L188
[this Rust bug]: rust-lang/rust#22915

frewsxcv added a commit to rust-fuzz/afl.rs that referenced this issue Nov 18, 2017

Rewrite of afl.rs; introduction of cargo-afl. (#116)
* Rewerite of afl.rs; introduction of cargo-afl.

Before
======

AFL is a coverage guided fuzzer. Prior to these changes, afl.rs
would rely on [an LLVM pass] to instrument the fuzz target and get
insight into the code branches hit by the fuzzer.

Depending on the user's system, sometimes the ABI stars would align and
this would work. But [seemingly most of the time][problems], it was a
headache for many users.

[an LLVM pass]: https://github.com/rust-fuzz/afl.rs/tree/6d5b5256d7a9a4909a00ba86501be7c9687cd56e/afl-plugin
[problems]: #57

After
====

With these changes, the LLVM pass is no longer necessary. Instead of
using AFL's own LLVM pass for instrumentation, this pull request
migrates to LLVM's built-in execution tracing feature
`trace-pc-guard` which [AFL supports].

Effectively, these changes makes fuzzing Rust code with AFL _much_
easier than before. In particular:

- No longer requires unstable Rust features
- Works on all Rust channels (stable, beta, nightly)
- No longer need to modify the Rust crate being fuzzed, just write the
  fuzz target
- Linux-only for now, but if [this Rust bug] gets fixed, it'll work on macOS

[AFL supports]: https://github.com/mirrorer/afl/blob/2fb5a3482ec27b593c57258baae7089ebdc89043/llvm_mode/README.llvm#L169-L188
[this Rust bug]: rust-lang/rust#22915

* progress

* progress

* progress

* progress

* progress

* reapi a thing

* remove a bunch of unnecessarily committed files

* ignore basically everything in the afl dir

* make tests pass

@frewsxcv frewsxcv referenced this issue Nov 19, 2017

Closed

Mac support #118

@PaulGrandperrin

This comment has been minimized.

Show comment
Hide comment
@PaulGrandperrin

PaulGrandperrin Feb 21, 2018

Hi, I just want to point out that it seems to me that this bug is fixed in rust beta and nightly.
You can see here that the bug was triggered on rust stable:
https://travis-ci.org/rust-fuzz/honggfuzz-rs/jobs/344493069#L120
But is now fixed on rust beta and nightly:
https://travis-ci.org/rust-fuzz/honggfuzz-rs/builds/344493067

PaulGrandperrin commented Feb 21, 2018

Hi, I just want to point out that it seems to me that this bug is fixed in rust beta and nightly.
You can see here that the bug was triggered on rust stable:
https://travis-ci.org/rust-fuzz/honggfuzz-rs/jobs/344493069#L120
But is now fixed on rust beta and nightly:
https://travis-ci.org/rust-fuzz/honggfuzz-rs/builds/344493067

PaulGrandperrin added a commit to rust-fuzz/honggfuzz-rs that referenced this issue Feb 21, 2018

@frewsxcv

This comment has been minimized.

Show comment
Hide comment
@frewsxcv

frewsxcv Feb 25, 2018

Member

just confirmed this is fixed for me too! afl.rs now works on mac

Member

frewsxcv commented Feb 25, 2018

just confirmed this is fixed for me too! afl.rs now works on mac

@frewsxcv

This comment has been minimized.

Show comment
Hide comment
@frewsxcv

frewsxcv Feb 25, 2018

Member

Gonna close this. If anyone else encounters this, let me know and I'll reopen

Member

frewsxcv commented Feb 25, 2018

Gonna close this. If anyone else encounters this, let me know and I'll reopen

@frewsxcv frewsxcv closed this Feb 25, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment