Speaking of folding bikes, @xtaran passed along this question from @stereo4x4
Q6. Oh no, my 1970s #foldingbike seems to turn into a brake-in-half-bike soon.
Any recommendations? Just clean the area and MIG #weld it? Add some reinforcement?
Oh no, my 1970s #foldingbike seems to turn into a brake-in-half-bike soon.
Any recommondations? Just clean the area and MIG #weld it? Add some reinforcement?
Die Fragen basieren auf rechtsextremen Narrativen, à la "staatsfinanzierter Meinungsmache" (konkret z.B. mit Verweis auf "Deep State" Artikel in #WELD), bis zu "NGOs eine Schattenstruktur".
Pure Verschwörungsrhetorik – als ob Greenpeace & Co. heimlich die Republik steuern. 2/
Finally been able to produce a tiny executable:
```
$ cat exit.s
section .text
global _start
_start:
mov edi, 42 ; return code 42
mov eax, 60 ; `_exit` syscall
syscall
$ nasm -f elf64 exit.s -o exit.o
$ cargo run -- --target x86_64-unknown-unknown exit.o -o a.out
$ [go on a x86-64 Linux machine]
$ chmod u+x a.out
$ ./a.out
$ echo $?
42
```
That's a first step! Patches are coming.
Finally got time to work on this. Have produced my first ELF executable but it doesn’t run… yet. Learning the hard way! The more I dig, the more I learn, which is the primary goal of this project. Stay tuned!
After a long hibernation, the project is now awaken. I've updated the dependencies, and I've committed pending changes on the `Read` and `Write` traits of the `weld-object` crate.
Nothing fancy, but I can work on it now, https://github.com/Hywan/weld/commit/62c439fb394ced6699169b78ec43b27d3b757e19.
My biggest difficulty with linkers is… understanding their errors! I know I'm not alone.
That's why `weld` must be exemplary on errors, period.
Please welcome `weld-errors`, https://github.com/Hywan/weld/compare/b7fde2dbf9fb523dccb041063bfd030967f5e814...4a41bd666c6dc8b76a59bf7c127247312e84127e.
What's new?
* Any error contains a code, a (formatted) message, and a help message,
* `weld` pretty prints those errors,
* `weld --explain <error_code>` gives detailed diagnostics,
* Automatic awesome documentation.
See the screenshots.
`weld` now takes a `--target <triple>` argument. `weld` is designed to be cross-platform entirely, hence it's legit to be able to specify a target triple, https://github.com/Hywan/weld/commit/b7fde2dbf9fb523dccb041063bfd030967f5e814.
Based on the provided target triple, `weld` will use a particular linker strategy (e.g Elf, MachO, Coff, Wasm etc.).
$ weld --target x86-64-unknown-linux <input> -o <output> # = Elf
$ weld --target aarch64-apple-darwin <input> -o <output> # = MachO
Cool huh?
ˋweld-object` is now able to disassemble x86 instructions when debugging an object file (with the ˋdebug-x86` feature turned on), https://github.com/Hywan/weld/commit/043e16d731108ac1a7cade05de209a18e0591959.
It’s really handy :-)!
It’s based on the excellent iced-x86 crate, https://github.com/icedland/iced.
If you know an equivalent for ARM, please let me know!
A little improvement on the scheduler to make it more system friendly.
`ThreadPool` no longer takes a ˋpool_sizeˋ but a ˋdesired_pool_sizeˋ. The system might not have all the expected available parallelism resources. Maybe it is busy, maybe it is limited. So now, the pool size is clamped, https://github.com/Hywan/weld/commit/8590fa4f5c80b5c827c0e928226d5b5bbd231f2c. The documentation provides more details.
Hopefully Rust has a standard function for that: `std::thread::available_parallelism`. How neat!
To be fast, weld needs to link objects concurrently & simultaneously. A few days ago, I’ve implemented a simple `ThreadPool` type, in the new `weld-scheduler` crate, https://github.com/Hywan/weld/blob/ea792c808887306acc6985bd71910fc35051a530/crates/scheduler/src/lib.rs.
It’s able to send `Future`s on various threads where async workers execute them.
It’s done with smol, a light & flexible set of crates to implement custom async runtimes, https://github.com/smol-rs/smol.
Next step: “Linker Strategy” to link things for real!
Later on, I've added a new patch to make the `FileReader` trait thread-safe, https://github.com/Hywan/weld/commit/3078ab77176b333fb9db0820c24f7c0d09ac23f8.
Just a detail, because something funnier is coming :-).
To be able to link many object files, we must be able to read them! Of course, there is `std::fs`, but we want to be fast right? So let's use mmap.
Oh, it's not available everywhere. So let's use a file picker, don't you mind, which will select the best implementation for your platform.
And here is `weld-file`, https://github.com/Hywan/weld/compare/7556abeb5d80f015e92634d8b9a6c1494e815b9e...f19d8bae61ef61c443d974bcf3d0a3101a69e7b3.
So far, it supports `std::fs` and `mmap`, more is coming
There is a `FileReader` trait, that reads the content async.
The `weld-parser` crate wasn't happy with its name. Now, we must refer to it as `weld-object`. This crate has ambitions for its life!, like supporting Elf32, MachO, COFF, and more object formats, look at this little cheeky!
https://github.com/Hywan/weld/commit/7556abeb5d80f015e92634d8b9a6c1494e815b9e
Before leaving the elf64, I wanted to write some tests. Fortunately for me, parsers written with nom are really easy to test, they are just functions!
When tests are easy to write, it's a pleasure to test everything.
With this test session, I've been able to fix one panic when reading a string in a data segment with an out-of-range offset.
