ok, that implies I will need to upgrade our uClibc version in our toolchain/env, nightmares ahead... but I understand. Thanks

Just fyi. The dl_iterate_phdr is present in the latest uclibc release here and added in this commit. As such, I've managed to create a pull request for libc to include dl_iterate_phdr for uclibc here. I'm not sure if that changes anything with respect to this pull request, I just thought it might be relevant.

ok this is released in 0.3, which rolls up several things from past few months; it's a breaking change because one part of the mach-o api changed, but otherwise it should be fine

ok this is wrapped up in upcoming 0.3 release

whoops, forgot about this, will release now!

Something like

trait Registers {
    fn ip(&self) -> u64;
    fn set_ip(&mut self, ip: u64);
    fn sp(&self) -> u64;
    fn set_sp(&mut self, sp: u64);
    fn bp(&self) -> Option<u64>; // None if the standard abi on the platform has no base pointer
    #[must_use]
    fn set_bp(&mut self, bp: u64) -> Option<()>; // None if the standard abi on the platform has no base pointer

    fn reg_for_dwarf(&self, reg: gimli::Register) -> Option<u64>; // None when register doesn't exist
    #[must_use]
    fn set_reg_for_dwarf(&mut self, reg: gimli::Register, val: u64) -> Option<()>; // None when register doesn't exist

    fn name_for_dwarf(reg: gimli::Register) -> Option<&'static str>; // None when register doesn't exist
    fn dwarf_for_name(name: &str) -> Option<gimli::Register>; // None when register doesn't exist
}

I am not quite sure how to handle different reg sizes on different architectures and within a single architecture though.

Closed by #98

Implements #87.

• [x] Add trait definition.
• [x] Implement register functions for the Linux target.
• [x] Refactor the repl example to use the new API.
• [x] Refactor the gui example to use the new API.
• [x] Clean up the code and fix CI builds.

Great suggestion, thank you!

We can run non-x86 builds with qemu (like e.g. rust-lang/libc does) in order to ensure that Headcrab can still be built without errors on non-x86 platforms (even if it's not entirely functional).

This will help us to prepare for introducing more target_archs in the future.

@bjorn3 should be fixed now, thanks!

The rotate_left and rotate_right methods indirectly use intrinsics that lower to the rotl and rotr clif instructions. These are not yet supported for bit widths less than 32 bit. (https://github.com/bytecodealliance/wasmtime/issues/1045) If funty were to mark all methods as #[inline], which they likely should, this wouldn't be a problem unless they were actually used.

funty is a crate required by sqlx. To reproduce the build error, add this as a dependency:

funty = "1.0.1"

This is the error message I'm seeing:

thread 'rustc' panicked at 'ABI argument v5 should be in a register', /Users/aidan/.cargo/git/checkouts/wasmtime-41807828cb3a7a7e/1964036/cranelift/codegen/src/regalloc/coloring.rs:409:21
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

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/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.50.0-nightly (593fe977a 2020-11-20) running on x86_64-apple-darwin

note: compiler flags: -C embed-bitcode=no -C debuginfo=2 -C link-arg=-undefined -C link-arg=dynamic_lookup --crate-type lib

note: some of the compiler flags provided by cargo are hidden

query stack during panic:
end of query stack
Instance { def: Item(WithOptConstParam { did: DefId(2:18122 ~ core[343e]::num::{impl#6}::rotate_left), const_param_did: None }), substs: [] } _ZN4core3num20_$LT$impl$u20$u8$GT$11rotate_left17h4a9f2e335f0d4da1E
error: could not compile `funty`

Awesome, thanks!

Published 0.8.0 (there were breaking API changes).

Also, @philipc I sent you an ownership invite so it isn't just me who owns this crate.

See https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Fwg-rls-2.2E0/topic/Live.20unit.20testing/near/217883005

With lazy compilation instrumenting would be trivial. It wouldn't even be necessary to add instrumentation calls in the jitted code. Just record the function call when you lazily compile a function. You could reset the GOT used for swapping all calls from the lazy compilation stub to the jitted code back to the lazy compilation stubs after every test and then as optimization keep a pointer to the jitted code in a side-table.

Any chance we can get a point release that includes this change? It's currently blocking https://github.com/getsentry/sentry-rust/pull/222.

Should get a #[cfg] as the register type depends on the target.

    struct EvalContext {

This is no longer x86_64 specific.

Ok! In that case this seems fine for now and it can always be updated later if necessary.

Exactly, in my required environment, the uClibc didn’t have those symbols.

We are not using the latest version of uClibc thought, as such, I am unclear how to deal with this. On Nov 24, 2020, 10:44 AM -0500, Alex Crichton [email protected], wrote:

Thanks for this! Is this perhaps indicative of missing bindings in the libc crate though? Presumably uclibc has support for these functions? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

Thanks for this! Is this perhaps indicative of missing bindings in the libc crate though? Presumably uclibc has support for these functions?

How can I make it so that I can build with cranelift, yet still be able to use Rust Analyzer (with Vim, for instance)? Currently they both delete each others cache (I believe), which results in compiling from scratch everytime I do an edit. How to bypass/fix this?