profile
viewpoint

m4b/goblin 537

An impish, cross-platform binary parsing crate, written in Rust

gimli-rs/gimli 408

A blazing fast library for consuming the DWARF debugging format

m4b/faerie 179

Magical ELF and Mach-o object file writer backend

gimli-rs/ddbug 35

Display debugging information

gimli-rs/leb128 9

Read and write DWARF's "Little Endian Base 128" variable length integer encoding

philipc/findpanics 8

Find calls to panic functions in rust executables

pull request commentrust-lang/backtrace-rs

disable dl_iterate_phdr for uclibc

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

ykoehler

comment created time in 12 hours

pull request commentrust-lang/backtrace-rs

disable dl_iterate_phdr for uclibc

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.

ykoehler

comment created time in 14 hours

pull request commentm4b/goblin

elf: prevent overflow

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

jackcmay

comment created time in 21 hours

push eventm4b/goblin

m4b

commit sha 2df1c472cc25a45f20cfdcff53d5fffe5d523fa0

build: bump version to 0.3.0 Breaking because mach min version api changed slightly.

view details

m4b

commit sha 085761a6dc20f62ffd854b7f1e537d25138bc67d

build: update changelog

view details

m4b

commit sha 15e99d00407f8d9e184a7d03cb1ed4f89a5eeecf

build: add 4 new contributors to contributors!

view details

push time in 21 hours

pull request commentm4b/goblin

mach/load_command: Add some missing load commands

ok this is wrapped up in upcoming 0.3 release

woodruffw

comment created time in 21 hours

pull request commentm4b/goblin

elf: prevent overflow

whoops, forgot about this, will release now!

jackcmay

comment created time in a day

issue closedheadcrab-rs/headcrab

Add a trait for registers

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 time in a day

bjorn3

issue commentheadcrab-rs/headcrab

Add a trait for registers

Closed by #98

bjorn3

comment created time in a day

push eventheadcrab-rs/headcrab

Nikita Baksalyar

commit sha e8f87aec51175880fa073d092ceea1d29c382ca0

Add target::registers::Registers trait This trait can be used to implement register reading & writing functions for target architectures.

view details

Nikita Baksalyar

commit sha 6ab52a2467bb0f472fbfee66ced13c5c50aac981

Implement x86_64 registers

view details

Nikita Baksalyar

commit sha 19c0b3c85713f18f8951567085d13dc652a2aa23

Add dummy registers implementation for macOS

view details

Nikita Baksalyar

commit sha 488a9d498188b781b0592861e175856a7e644a1f

Fix platform-specific naming and conditional compilation

view details

bjorn3

commit sha 8e9424a8a9d650a6a0242b0cbbb5f8e7388f9037

Merge pull request #98 from nbaksalyar/registers Add API to read & write registers for Linux

view details

push time in a day

PR merged headcrab-rs/headcrab

Add API to read & write registers for Linux

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.
+454 -193

1 comment

17 changed files

nbaksalyar

pr closed time in a day

issue commentheadcrab-rs/headcrab

Setup CI infrastructure to run non-x86 builds

Great suggestion, thank you!

nbaksalyar

comment created time in a day

issue openedheadcrab-rs/headcrab

Setup CI infrastructure to run non-x86 builds

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.

created time in a day

pull request commentheadcrab-rs/headcrab

Add API to read & write registers for Linux

@bjorn3 should be fixed now, thanks!

nbaksalyar

comment created time in a day

issue commentbjorn3/rustc_codegen_cranelift

Unable to compile funty on MacOS

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.

vultix

comment created time in a day

create barnchbjorn3/rustc_codegen_cranelift

branch : wip_abi_refactor

created branch time in a day

issue openedbjorn3/rustc_codegen_cranelift

Unable to compile funty on MacOS

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`

created time in a day

pull request commentgimli-rs/findshlibs

Fix shlib len and add actual_load_address

Awesome, thanks!

jan-auer

comment created time in a day

pull request commentgimli-rs/findshlibs

Fix shlib len and add actual_load_address

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.

jan-auer

comment created time in a day

created taggimli-rs/findshlibs

tag0.8.0

Find the shared libraries loaded in the current process with a cross platform API

created time in a day

push eventgimli-rs/findshlibs

Nick Fitzgerald

commit sha 4f0819ff9661f4acdf88098e442bc302ddf34e64

Bump to version 0.8.0

view details

push time in a day

issue openedbjorn3/rustc_codegen_cranelift

Add option to instrument which functions are used by which test

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.

created time in 2 days

pull request commentgimli-rs/findshlibs

Fix shlib len and add actual_load_address

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

jan-auer

comment created time in 2 days

Pull request review commentheadcrab-rs/headcrab

Add API to read & write registers for Linux

 impl Thread for LinuxThread {     } } +/// Type alias to use for boxed threads.+type BoxedLinuxThread = Box<dyn Thread<RegistersX86_64, ThreadId = i32>>;

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

nbaksalyar

comment created time in 2 days

Pull request review commentheadcrab-rs/headcrab

Add API to read & write registers for Linux

 mod example {         Ok(())     } -    fn get_linux_x86_64_reg(-        regs: libc::user_regs_struct,-    ) -> impl Fn(gimli::Register, gimli::ValueType) -> gimli::Value {-        move |reg, ty| {-            let val = match reg {-                gimli::X86_64::RAX => regs.rax,-                gimli::X86_64::RBX => regs.rbx,-                gimli::X86_64::RCX => regs.rcx,-                gimli::X86_64::RDX => regs.rdx,-                gimli::X86_64::RSI => regs.rsi,-                gimli::X86_64::RDI => regs.rdi,-                gimli::X86_64::RSP => regs.rsp,-                gimli::X86_64::RBP => regs.rbp,-                gimli::X86_64::R9 => regs.r9,-                gimli::X86_64::R10 => regs.r10,-                gimli::X86_64::R11 => regs.r11,-                gimli::X86_64::R12 => regs.r12,-                gimli::X86_64::R13 => regs.r13,-                gimli::X86_64::R14 => regs.r14,-                gimli::X86_64::R15 => regs.r15,-                reg => unimplemented!("{:?}", reg), // FIXME-            };-            match ty {-                gimli::ValueType::Generic => gimli::Value::Generic(val),-                gimli::ValueType::U64 => gimli::Value::U64(val),-                _ => unimplemented!(),-            }-        }-    }-     struct X86_64EvalContext {
    struct EvalContext {

This is no longer x86_64 specific.

nbaksalyar

comment created time in 2 days

push eventrust-lang/backtrace-rs

Yannick Koehler

commit sha 47069af003d7f4ca62f5b4517a43039c46dfc34d

disable dl_iterate_phdr for uclibc (#396) Co-authored-by: Yannick Koehler <ykoehler@arubanetworks.com>

view details

push time in 2 days

pull request commentrust-lang/backtrace-rs

disable dl_iterate_phdr for uclibc

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

ykoehler

comment created time in 2 days

pull request commentrust-lang/backtrace-rs

disable dl_iterate_phdr for uclibc

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 notifications@github.com, 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.

ykoehler

comment created time in 2 days

pull request commentrust-lang/backtrace-rs

disable dl_iterate_phdr for uclibc

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

ykoehler

comment created time in 3 days

issue closedbjorn3/rustc_codegen_cranelift

How to use with Rust Analyzer?

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?

closed time in 3 days

Knarkzel
more