Skip to content
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.

Sign up for GitHub

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

Jump to bottom

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
Closed

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

alexchandel opened this issue Mar 1, 2015 · 8 comments
Labels
A-linkage Area: linking into static, shared libraries and binaries C-bug Category: This is a bug. O-macos Operating system: macOS

Comments

@alexchandel
Copy link

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
Copy link
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
Copy link
Member

nagisa commented Mar 1, 2015

Interesting. This call to get_metadata_section is the relevant code.

@alexchandel
Copy link
Author

@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 added the A-linkage Area: linking into static, shared libraries and binaries label Mar 2, 2015
@kmcallister kmcallister changed the title Target specification isn't specific enough on OS X. Invalid section names in Mach-O file on OS X w/ custom target spec Mar 2, 2015
@steveklabnik
Copy link
Member

Triage: no changes I'm aware of

@steveklabnik steveklabnik added the O-macos Operating system: macOS label May 24, 2016
@alexchandel
Copy link
Author

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.

@Mark-Simulacrum Mark-Simulacrum added the C-bug Category: This is a bug. label Jul 22, 2017
@nagisa nagisa mentioned this issue Nov 5, 2017
Closed
@frewsxcv frewsxcv mentioned this issue Nov 5, 2017
Open
frewsxcv added a commit to rust-fuzz/afl.rs that referenced this issue Nov 12, 2017
@frewsxcv
Rewerite of afl.rs; introduction of cargo-afl.
dc0310d 
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 frewsxcv mentioned this issue Nov 12, 2017
Merged
frewsxcv added a commit to rust-fuzz/afl.rs that referenced this issue Nov 12, 2017
@frewsxcv
Rewerite of afl.rs; introduction of cargo-afl.
ec773b3 
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
@frewsxcv
Rewerite of afl.rs; introduction of cargo-afl.
a0a593d 
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
@frewsxcv
Rewrite of afl.rs; introduction of cargo-afl. (#116)
f0517c6 
* 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 mentioned this issue Nov 19, 2017
Closed
@PaulGrandperrin
Copy link

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
@PaulGrandperrin
.travis.yml: Allow build failures on Rust stable on macOS
fa48732 
See: rust-lang/rust#22915
@frewsxcv
Copy link
Member

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

@frewsxcv
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-linkage Area: linking into static, shared libraries and binaries C-bug Category: This is a bug. O-macos Operating system: macOS
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
8 participants
@steveklabnik @frewsxcv @kmcallister @alexchandel @nagisa @huonw @PaulGrandperrin @Mark-Simulacrum