Comments (14)
I can investigate adding a no_std mode, but in this mode only basic things like the trait definitions will be exported. Most of the interesting runtime parts (executable memory handling) do require std. Particularly annoying is that alloc doesn't contain HashMap, so implementing the label API as only requiring alloc would require changes. Outside of that though, as long as you just define the methods required by the DynasmApi/DynasmLabelApi traits you can already use the plugin on nightly now.
from dynasm-rs.
I think it would be possible to have relocations functioning properly with the first approach. This is already how the x86 Assembler backend deals with resizing its internal buffer, so copying the mechanism would be ok.
For the second approach, that would fully depend on the user being able to determine the code size ahead of time.
So the first approach is probably preferable (even though it'll cost a bit of extra memory due to the buffer copy involved).
from dynasm-rs.
std::io
, std::fmt
and friends are only used for Display/Debug implementations, which you probably don't need in no-std
environments anyway.
As such an environment is probably a lot more limited in needed features, only the basic assembler, label handling and relocation logic needs to be properly ported.
from dynasm-rs.
@losfair regarding leaving executable memory management to the user, the way current Assemblers are written is quite intertwined with this memory management, and there are a few ways I could go about this.
The first approach would be to just assemble into a temporary buffer, and then hand it over to the user to remap it (if necessary) after assembling. This would be OK for x64 but would not work for x86 as relocation information requires knowledge of the address the code will end up at.
The second approach would be to have the user reserve a large enough buffer at the start, and pass this to an Assembler for assembling. This would be ok on most instruction sets, as we can assume the buffer never moves. For bare metal situations this would probably be preferable as it works even on systems with complete manual memory management.
Finally, more complex approaches would be possible where dynasmrt would have an unsafe trait for memory management systems that the user could implement and use the full-fledged Assemblers. This would be more flexible but I'm not sure if there's any platforms that you would need this complexity on that do not have a functional libstd.
Do you have an idea of what would suit you best?
from dynasm-rs.
I'd prefer the first or the second method to keep things simple. However, I have a few questions about these two approaches:
-
For the first approach, is it possible to emit code with 0x0 as the base address and some relocation info, and allow the user to do relocation later, after code is properly set up for execution (which is somehow similar to how dynamic libraries work, I suppose)?
-
For the second approach, is it possible to determine the code size ahead of time so that we can allocate just the exact size and avoid wasting memory?
from dynasm-rs.
hashbrown
works with alloc
only AFAIK.
from dynasm-rs.
Are there any plans on implementing this? I am asking because I am looking for no_std
support in Wasmer which uses this crate for code generation. I could also try to implement this if there are mentoring instructions to it.
from dynasm-rs.
@1c3t3a Currently not from my side, but I'd be happy to assist with mentoring. The runtime support crate got some significant rework since this issue was opened in order to separate label, memory and relocation handling, which should make the required changes easier to implement.
from dynasm-rs.
Shouldn't it be pretty easy to add no_std + alloc support with no-std-compat?
from dynasm-rs.
That wouldn't work apparently, as no-std-compat
doesn't handle std::io
(how should it in an environment where it's unclear if there even is a filesystem).
from dynasm-rs.
Any updates on this? I'm also interested in using wasmer in a no_std environment where I do have alloc support.
from dynasm-rs.
Unfortunately I don't think anyone picked this up. I don't think I'll handle this one myself but I'd be happy to mentor / answer questions if anyone wants to work on it.
from dynasm-rs.
Fair enough. I saw there is a pull request open for no_std support, but I have no idea how far in progress it is. Regardless, I think even if this library supported no_std, wasmer would still require a bunch of work to become no_std compatible anyway. I'll simply have to take a look at the existing PR and see what I can do. Thanks for the work on dynasm though!
from dynasm-rs.
I completely forgot about that one, whoops. I also don't have any idea how up-to-date it is, but it is probably a good starting point!
from dynasm-rs.
Related Issues (20)
- Building assembler code in reverse HOT 6
- Incorrect instruction encoding on AArch64 when using `xzr` as the destination register HOT 4
- Instruction cache not flushed after calling Assembler::alter on AArch64 HOT 11
- Partial `mprotect` on executable memory HOT 2
- The memmap crate is no longer maintained. HOT 8
- Incorrect instruction encoding on aarch64 HOT 4
- Is emitting text output possible? HOT 2
- Broken link to the documentation HOT 2
- How to choose assembler for shellcode generation HOT 2
- Impossible relocation on x86 HOT 2
- Panic when trying to use 0xff as immediate for a logical operation HOT 6
- Switch to github actions
- Can't encode repne scasb HOT 1
- Website link in the repo's "About" section is wrong HOT 3
- Example of how to run a PE32 executable/library? HOT 7
- Feature request: compile-time resolution of "super-local" label HOT 5
- Language dialect reference for AArch64 has some stale x86/x86-64 references HOT 2
- omit known zero offset HOT 2
- Consider using `MAP_JIT` on macOS HOT 1
- Link to GitHub pages is broken HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from dynasm-rs.