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

Properly collect/identify used DWARF entries. #186

Merged
merged 5 commits into from
Jul 17, 2019
Merged

Properly collect/identify used DWARF entries. #186

merged 5 commits into from
Jul 17, 2019

Conversation

yurydelendik
Copy link
Contributor

The patch:

  • Upgrades gimli
  • Adds dependency scanner
  • Improves performance of address lookups

@yurydelendik yurydelendik mentioned this pull request Jul 9, 2019
Merged
2 tasks
sunfishcode
sunfishcode reviewed Jul 11, 2019
View reviewed changes
wasmtime-environ/Cargo.toml Outdated Show resolved Hide resolved
wasmtime-debug/src/transform.rs Outdated Show resolved Hide resolved
wasmtime-debug/src/gc.rs Show resolved Hide resolved
@sunfishcode
Copy link
Member

Looks good!

@sunfishcode sunfishcode merged commit d27d190 into bytecodealliance:master Jul 17, 2019
sunfishcode pushed a commit that referenced this pull request Jul 17, 2019
@yurydelendik @sunfishcode
https://github.com/CraneStation/wasmtime/pull/186#discussion_r302781231
748abd9
@yurydelendik yurydelendik mentioned this pull request Nov 7, 2019
Closed
grishasobol pushed a commit to grishasobol/wasmtime that referenced this pull request Nov 29, 2021
@pepyakin
Add ARMv7 as CI test target (bytecodealliance#186)
7fe6ef4 
* Add ARMv7 as CI test target

* Avoid UB in conversions from floating point

When truncating floating point values to integer values, we need to
avoid undefined behavior if the argument does not fit into the target
type which is currently impossible using casts of primitive types.

Hence, this reimplements those conversions using arbitrary precision
integers and rationals from the num crate.
grishasobol pushed a commit to grishasobol/wasmtime that referenced this pull request Nov 29, 2021
@mystor
Fix wasmi no_std support (bytecodealliance#230)
d186a3d 
* Fix wasmi no_std support (bytecodealliance#218)

Two issues are fixed:

 1. num-bigint 0.2 requires std, and is used to perform float to int conversions
    since bytecodealliance#186. This patch disables this change in no_std environments.
    This change can be reverted once num-bigint 0.3 is released, which will
    support no_std.

 2. The `f{32,64}::fract` method is currently not implemented by core, only std.
    This patch uses the no_std supporting implementation from num-trait's
    FloatCore trait.

* Ensure wasmi builds without std in CI

The no-std-check cargo subcommand uses a custom sysroot to prevent the crate
from using std while checking a local target. This should help ensure that
changes which introduce std dependencies are caught at review time.
mooori pushed a commit to mooori/wasmtime that referenced this pull request Jan 26, 2024
@aborg-dev
Merge pull request bytecodealliance#186 from near/stack_fixes
f1231ff 
Align stack handling with other architectures
dhil pushed a commit to dhil/wasmtime that referenced this pull request Jun 12, 2024
@frank-emrich
Prepare static tables for non-pointer-sized entries (bytecodealliance…
5902623 
…#192)

This PR provides a prerequisite for bytecodealliance#186, by implementing a solution for
a problem originally described
[here](wasmfx#186 (comment)).

To reiterate, the problem is as follows:
For "static" tables (= tables managed my a `TablePool`), the `TablePool`
manages a single mmapped memory region from which it allocates all
tables. To this end, it calculates the required overall size of this
region as `max_number_of_allowed_tables` *
`max_allowed_element_count_per_table` * `size_of_each_table_entry`.
Thus, the memory for table with index i in the pool then starts at i *
`max_allowed_element_count_per_table` * `size_of_each_table_entry`.

However, all of this is based on the (hardcoded) assumption that all
table entries across all table types are pointer-sized (i.e.,
`size_of_each_table_entry` is `sizeof(*mut u8))`. But once bytecodealliance#186 lands,
this is not the case any more.

This PR addresses this as follows:

1. Change the calculation of the overall size of the mmapped region to
`max_number_of_allowed_tables` * `max_allowed_element_count_per_table` *
`max_size_of_each_table_entry`, where `max_size_of_each_table_entry`
will be `sizeof(VMContObj)` == 16 once bytecodealliance#186 lands. This effectively
doubles the amount of address space occupied by the table pool. The
calculation of the start address of each table is changed accordingly.
2. Change the logic for allocating and deallocating tables from the pool
so that we take the element size for that particular table type into
account when committing and decommitting memory.

Note that the logic implemented this PR is independent from the
underlying element sizes. This means that this PR itself does not change
the space occupied by the tables, as `max_size_of_each_table_entry` is
currently still the size of a pointer. The necessary changes happen
implicitly once bytecodealliance#186 lands, which changes the size of `ContTableElem`
which in turns changes the constant `MAX_TABLE_ELEM_SIZE`.

In summary, these changes mean that in the future the table pool
occupies more virtual address space, but the amount of actually
committed pages for non-continuation tables does not change.
dhil pushed a commit to dhil/wasmtime that referenced this pull request Jun 13, 2024
@frank-emrich
Use 128 bit fat pointers for continuation objects (bytecodealliance#186)
78b813d 
This PR changes the representation introduced in bytecodealliance#182 , where
continuation objects were turned into tagged pointers, containing a
pointer to a `VMContRef` as well as a 16bit sequence counter to perform
linearity checks.

In this PR, the representation is changed from 64bit tagged pointers to
128bit fat pointers, where 64bit are used for the pointer and the
sequence counter.

Some implementation details:
- The design introduced in bytecodealliance#182, where we use `disassemble_contobj` and
`assemble_contobj` to go from effectively `Optional<VMContObj>` to
`Optional<VMContRef>` is preserved.
- The feature `unsafe_disable_continuation_linearity_check` is
preserved: If it is enabled, we do not use fat (or tagged) pointers at
all, and all revision checks are disabled.
- Overflow checks for the revision counter are no longer necessary and
have been removed.
- In wasm, we now use the SIMD type `I8X16` for any value of type `(ref
$continuation)` and `(ref null $continuation)`. See the comment on
`vm_contobj_type` in shared.rs for why we cannot use `I128` or `I64X2`
instead.
- Some `translate_*` functions in the `FuncEnvironment` trait now need
to take a `FunctionBuilder` parameter, instead of `FuncCursor`, which
slightly increases the footprint of this PR.
- The implementation of `table.fill` for continuation tables was
missing. I've added this and in the process extended `cont_table.wast`
to be generally more exhaustive.
- For those libcalls that take a parameter that is a variant type
including `VMContObj`, I've introduced dedicated versions for the
`VMContObj` case, namely `table_fill_cont_obj` and `table_grow_cont_obj`
in libcalls.rs. These manually split the `VMContObj` into two parts.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@sunfishcode sunfishcode Awaiting requested review from sunfishcode

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@yurydelendik @sunfishcode