Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

switch from region to memmap? #10

Closed
sunfishcode opened this issue Aug 6, 2018 · 7 comments
Closed

switch from region to memmap? #10

sunfishcode opened this issue Aug 6, 2018 · 7 comments

Comments

@sunfishcode
Copy link
Member

#9 proposes ading a dependency on memmap, so we should consider using memmap rather than region for executable memory too.
@pepyakin
Copy link
Contributor

pepyakin commented Aug 6, 2018

Yeah, I thought about that, by the memmap API conflates this: map_exec takes File parameter. In our case we want anonymous mapping.

@sunfishcode
Copy link
Member Author

That's ok. We don't want the memory to be executable until after we write to it. We allocate normal anonymous pages and set the protection when they're ready.

@pepyakin
Copy link
Contributor

pepyakin commented Aug 6, 2018

Hm, and for that we would need region since memmap doesn't have such APIs, don't we?

@sunfishcode
Copy link
Member Author

Could make_read_only and make_exec do it? It's a little unfortunate that there doesn't seem to be a way to do both at the same time though.

@pepyakin
Copy link
Contributor

pepyakin commented Aug 6, 2018

oh, sorry, didn't know about those!

@sunfishcode
Copy link
Member Author

Actually, it looks like make_exec should be sufficient to also make the memory read-only.

@sunfishcode
Copy link
Member Author

A complicating factor with memmap is that it doesn't naturally support allocations consisting of some writeable pages and non-non-writeable pages. And other than this specialized need, we don't need a lot of other features, so I decided to just implement mmap support directly for now.

kubkon pushed a commit that referenced this issue Nov 7, 2019
@sunfishcode
Merge pull request #10 from CraneStation/api
a200b21 
Add experimental struct with views into memory and ctx
fitzgen added a commit to fitzgen/wasmtime that referenced this issue Nov 15, 2021
@fitzgen @cfallin
Make sure that infallible match operations come after fallible ones
037db8a 
Eventually we will probably want to sort by a partial ordering based on pattern
subsumption to break ties between rules with the same priority. This local
heuristic of making sure infallibilty comes last is good enough for now and
handles the cases we care about thus far.

Fixes bytecodealliance#10
grishasobol pushed a commit to grishasobol/wasmtime that referenced this issue Nov 29, 2021
@NikVolf
Merge pull request bytecodealliance#10 from pepyakin/couple-of-fixes
273eba2 
Couple of fixes
dhil added a commit to dhil/wasmtime that referenced this issue Sep 25, 2023
@dhil
Use hotfixed wasmfx-tools (bytecodealliance#10)
bbe66a8 
This patch uses release `wasmfx-tools-1.0.42.rev+1`.
mooori pushed a commit to mooori/wasmtime that referenced this issue Dec 20, 2023
@nagisa
zkasm: delete a boatload of RISC-V specific code (bytecodealliance#10)
9b0d904 
* zkasm: delete a boatload of RISC-V specific code

A downside of doing it the "copy riscv" way is that we have a ton of
types and stuff that are specific to how RISC-V architecture works. A
prime example of that is `AluRRImm12` type – RISC-V instruction encoding
does not support immediates that are larger than 12 bits in most cases,
so the backend needs to keep that in mind.

In principle if we did it from scratch instead we'd avoid having all of
the optimization-oriented special cases and rules, and would be able to
specify just the rules how to convert operations between two registers
and such.

* Implement LoadConst32/64
github-merge-queue bot pushed a commit that referenced this issue Feb 4, 2025
@abrown @alexcrichton
asm: introduce a new x64 assembler (#10110)
0e05600 
* asm: add initial infrastructure for an external assembler

This change adds some initial logic implementing an external assembler
for Cranelift's x64 backend, as proposed in RFC [#41].

This adds two crates:
- the `cranelift/assembler/meta` crate defines the instructions; to
  print out the defined instructions use `cargo run -p
  cranelift-assembler-meta`
- the `cranelift/assembler` crate exposes the generated Rust code for
  those instructions; to see the path to the generated code use `cargo
  run -p cranelift-assembler`

The assembler itself is straight-forward enough (modulo the code
generation, of course); its integration into `cranelift-codegen` is what
is most tricky about this change. Instructions that we will emit in the
new assembler are contained in the `Inst::External` variant. This
unfortunately increases the memory size of `Inst`, but only temporarily
if we end up removing the extra `enum` indirection by adopting the new
assembler wholesale. Another integration point is ISLE: we generate ISLE
definitions and a Rust helper macro to make the external assembler
instructions accessible to ISLE lowering.

This change introduces some duplication: the encoding logic (e.g. for
REX instructions) currently lives both in `cranelift-codegen` and the
new assembler crate. The `Formatter` logic for the assembler `meta`
crate is quite similar to the other `meta` crate. This minimal
duplication felt worth the additional safety provided by the new
assembler.

The `cranelift-assembler` crate is fuzzable (see the `README.md`). It
will generate instructions with randomized operands and compare their
encoding and pretty-printed string to a known-good disassembler,
currently `capstone`. This gives us confidence we previously didn't have
regarding emission. In the future, we may want to think through how to
fuzz (or otherwise check) the integration between `cranelift-codegen`
and this new assembler level.

[#41]: bytecodealliance/rfcs#41

* asm: bless Cranelift file tests

Using the new assembler's pretty-printing results in slightly different
disassembly of compiled CLIF. This is because the assembler matches a
certain configuration of `capstone`, causing the following obvious
differences:

- instructions with only two operands only print two operands; the
  original `MInst` instructions separate out the read-write operand into
  two separate operands (SSA-like)
- the original instructions have some space padding after the
  instruction mnemonic, those from the new assembler do not

This change uses the slightly new style as-is, but this is open for
debate; we can change the configuration of `capstone` that we fuzz
against. My only preferences would be to (1) retain some way to visually
distinguish the new assembler instructions in the disassembly
(temporarily, for debugging) and (2) eventually transition to
pretty-printing instructions in Intel-style (`rw, r`) instead of the
current (`r, rw`).

* ci: skip formatting when `rustfmt` not present

Though it is likely that `rustfmt` is present in a Rust environment,
some CI tasks do not have this tool installed. To handle this case
(plus the chance that other Wasmtime builds are similar), this change
skips formatting with a `stderr` warning when `rustfmt` fails.

* vet: audit `arbtest` for use as a dev-dependency

* ci: make assembler crates publishable

In order to satisfy `ci/publish.rs`, it would appear that we need to use
a version that matches the rest of the Cranelift crates.

* review: use Cargo workspace values

* review: document `Inst`, move `Inst::name`

* review: clarify 'earlier' doc comment

* review: document multi-byte opcodes

* review: document `Rex` builder methods

* review: document encoding rules

* review: clarify 'bits' -> 'width'

* review: clarify confusing legacy prefixes

* review: tweak IA-32e language

* review: expand documentation for format

* review: move feature list closer to enum

* review: add a TODO to remove AT&T operand ordering

* review: move prefix emission to separate lines

* review: add testing note

* review: fix incomplete sentence

* review: rename `MinusRsp` to `NonRspGpr`

* review: add TODO for commented out instructions

* review: add conservative down-conversion to `is_imm*`

* Fuzzing updates for cranelift-assembler-x64 (#10)

* Fuzzing updates for cranelift-assembler-x64

* Ensure fuzzers build on CI
* Move fuzz crate into the main workspace
* Move `fuzz.rs` support code directly into fuzzer
* Move `capstone` dependency into the fuzzer

* Make `arbitrary` an optional dependency

Shuffle around a few things in a few locations for this.

* vet: skip audit for `cranelift-assembler-x64-fuzz`

Co-authored-by: Alex Crichton <[email protected]>

* review: use 32-bit form for 8-bit and 16-bit reg-reg

Cranelift's existing lowering for 8-bit and 16-bit reg-reg `AND` used
the wider version of the instruction--the 32-bit reg-reg `AND`. As
pointed out by @cfallin [here], this was likely due to avoid partial
register stalls. This change keeps that lowering by distinguishing more
precisely between `GprMemImm` that are in register or memory.

[here]: #10110 (comment)

* fix: skip `rustfmt` on generated code in more cases

Apparently `rustfmt` is not found on the `x86_64-unknown-illumos` build.
This change skips the action in this new case.

prtest:full

* fix: feed Cargo the meta crate version

This fixes errors with the `publish.rs` script.

prtest:full

---------

Co-authored-by: Alex Crichton <[email protected]>
dicej added a commit to dicej/wasmtime that referenced this issue Feb 14, 2025
@dicej
save and restore CallContext for host tasks
b98d5f8 
We were already doing this for guest tasks, but I missed doing it for host
tasks, leading to "cannot remove owned resource while borrowed" errors.

Fixes bytecodealliance#10.

Signed-off-by: Joel Dice <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@pepyakin @sunfishcode