goblin VS wg-allocators

On the backend side, a lot has changed. The biggest change is that the dependency on Boost has been completely removed, and everything has been reworked accordingly. This should make packaging easier, as yabridge now no longer depends on any system library other than the basic libraries needed to interact with X11. Some parts of Boost have been replaced by other headers-only libraries, while other parts now simply use custom implementations. All of this is explained in more detail in the 'Packaging notes' section of the changelog. Yabridgectl also lost its dependency on winedump, at least in most cases. It now tries to parse plugin libraries directly using the goblin binary parsing library. This should also speed up the syncing process. I did, however, run into one plugin that this new parser couldn't handle. If that happens then winedump will still be used instead.

For now the minidump creation is a fairly faithful port of the Breakpad code, but like I said some of that code is really old, so there's probably cases where taking a step back and rethinking the approach based on new kernel or OS capabilities or, instead of recreating process snapshotting for each non-Windows, just have a really good parser for each OSes crash format that does a transform. Rust is a fantastic language for writing those kinds of parsers, so that would definitely be an interesting avenue to investigate, especially since in the Linux case a lot of groundwork has already been done by goblin.

I do security-related projects in Rust, and goblin has been my go-to crate for any type of binary parsing (ELF/PE/Mach-O).

Tracking issue for Storages, and a TLDR on what it is

I must have gotten confused, since from your brief discussion with CAD97 it seemed like there was a way for the concepts to live separately and that Storage could complicate things in comparison. But if implementing Allocator in terms of Storage is basically equivalent and Storage is flexible enough that I could write one to pass memory out to unsafe code, that works just as well.

https://rust-lang.github.io/rfcs/1974-global-allocators.html was the original RFC.

My vague understanding is that there's a working group https://github.com/rust-lang/wg-allocators

The further I get from working on Rust day to day, the less I know about these things, so that's all I've got for you.

If you self-reference using pointers and guarantee the struct will never move, you don't even need unsafe. If you self-reference using offsets from the struct's base pointer, you need a splash of unsafe but your struct can be freely moved without invalidating its self-referential "pointers".

Per-struct allocators are a work in progress (see https://github.com/rust-lang/wg-allocators/issues/48).

Not sure what "non thread local addresses" means, but in my experience Rust is pretty good at sending data between threads (without moving it).

Besides that allocation is not really a problem for no_std. It's resolved by using alloc crate directly, so anything usable with custom allocators is supported. Example in dasp sources - https://github.com/RustAudio/dasp/blob/master/dasp_slice/src/boxed.rs#L14-L19 . Also worth looking at this issue to check what is usable already - https://github.com/rust-lang/wg-allocators/issues/7

But that's on track for rust as well: https://github.com/rust-lang/wg-allocators/issues/7

Here: https://github.com/rust-lang/rfcs/pull/1398. there is also a working group for this: https://github.com/rust-lang/wg-allocators.

It's unstable. wg-allocators contains discussions about design and a tracking issue for collections that need an allocator https://github.com/rust-lang/wg-allocators/issues/7