profile
viewpoint

bytecodealliance/wasmtime 3134

Standalone JIT-style runtime for WebAssembly, using Cranelift

bytecodealliance/cranelift 2488

Cranelift code generator

bytecodealliance/wasmparser 177

A simple event-driven library for parsing WebAssembly binary files

fitzgen/bindgen-tutorial-bzip2-sys 44

A tutorial/example crate for generating C/C++ bindings on-the-fly with libbindgen

CraneStation/wasmtime-wasi 24

WASI suppport for wasmtime

fitzgen/associative-cache 8

A generic, fixed-size, associative cache

fitzgen/ada-scheme 5

Following along with Peter Michaux's Scheme from Scratch series (http://peter.michaux.ca/articles/scheme-from-scratch-introduction) in Ada

bytecodealliance/wasmtime-libfuzzer-corpus 3

libFuzzer corpus for our wasmtime fuzz targets

issue closedmsurguy/cnc-text-tool

"<" and ">" characters get stripped from the input text

Steps to reproduce:

  • upload empty.svg into the tool

    <details>

    <summary><code>empty.svg</code></summary>

    <svg xmlns="http://www.w3.org/2000/svg">
    </svg>
    

    </details>

  • type Uniform<i64> into the input text box

  • download the resulting svg

Expected results:

The downloaded SVG has the text with its < and > characters: Uniform<i64>

Actual results:

The downloaded SVG has the text without the < and > characters: Uniformi64


Thanks for making this tool!

closed time in a day

fitzgen

issue commentmsurguy/cnc-text-tool

"<" and ">" characters get stripped from the input text

Yep, it appears to be fixed now! Thanks!

fitzgen

comment created time in a day

push eventrustwasm/twiggy

Deployment Bot (from Travis CI)

commit sha d55997c0418e2e3b57497561e4df577aec3beb61

Deploy rustwasm/twiggy to github.com/rustwasm/twiggy.git:gh-pages

view details

push time in 2 days

issue openedbytecodealliance/wasmtime

Use virtual memory tricks to make interrupt checks smaller and faster

Right now, to check if for interrupts:

  • we load the interrupts pointer from the vmctx
  • we dereference it to get the maybe-interrupted value
  • we compare that against the interrupt-has-been-requested value
  • and finally we conditionally trap when the comparison returned true.

There is no fast/slow path split here. Interrupts happen rarely, but we always perform those four steps.

By using virtual memory tricks, we can create a fast path for the common case when no interrupts are requested. We reserve a page of memory as the "interrupt page" and point to it from the vmctx. This replaces the current interrupt pointer on the vmctx. When interrupts are not requested, this page is readable. When an interrupt is requested, remove the readable bit via mprotect, and wait.

Now, all that our loop headers do is:

  • load the pointer to the interrupts page from the vmctx
  • (attempt to) read the first byte from the interrupts page

When the interrupts page is readable and an interrupt is not requested, we just have those two loads as our fast path.

When the interrupts page is not readable because an interrupt is requested, a signal is generated, so our signal handler needs to recognize+handle this case.

IIRC, essentially this same trick is used in some JVMs for synchronizing at safepoints for stop-the-world GC phases (e.g. root marking).

The one open question is how to detect stack overflows with this setup, since our interrupt handling and stack overflow code is very intertwined. Not totally sure here.

+cc @alexcrichton

created time in 4 days

push eventfitzgen/wasmtime

Nick Fitzgerald

commit sha 8a136b7b1dcff43618f338aa38eab882beca543a

runtime: Introduce `VMExternRef` and `VMExternData` `VMExternRef` is a reference-counted box for any kind of data that is external and opaque to running Wasm. Sometimes it might hold a Wasmtime thing, other times it might hold something from a Wasmtime embedder and is opaque even to us. It is morally equivalent to `Rc<dyn Any>` in Rust, but additionally always fits in a pointer-sized word. `VMExternRef` is non-nullable, but `Option<VMExternRef>` is a null pointer. The one part of `VMExternRef` that can't ever be opaque to us is the reference count. Even when we don't know what's inside an `VMExternRef`, we need to be able to manipulate its reference count as we add and remove references to it. And we need to do this from compiled Wasm code, so it must be `repr(C)`! `VMExternRef` itself is just a pointer to an `VMExternData`, which holds the opaque, boxed value, its reference count, and its vtable pointer. The `VMExternData` struct is *preceded* by the dynamically-sized value boxed up and referenced by one or more `VMExternRef`s: ```ignore ,-------------------------------------------------------. | | V | +----------------------------+-----------+-----------+ | | dynamically-sized value... | ref_count | value_ptr |---' +----------------------------+-----------+-----------+ | VMExternData | +-----------------------+ ^ +-------------+ | | VMExternRef |-------------------+ +-------------+ | | +-------------+ | | VMExternRef |-------------------+ +-------------+ | | ... === | +-------------+ | | VMExternRef |-------------------' +-------------+ ``` The `value_ptr` member always points backwards to the start of the dynamically-sized value (which is also the start of the heap allocation for this value-and-`VMExternData` pair). Because it is a `dyn` pointer, it is fat, and also points to the value's `Any` vtable. The boxed value and the `VMExternRef` footer are held a single heap allocation. The layout described above is used to make satisfying the value's alignment easy: we just need to ensure that the heap allocation used to hold everything satisfies its alignment. It also ensures that we don't need a ton of excess padding between the `VMExternData` and the value for values with large alignment.

view details

Nick Fitzgerald

commit sha 42eec75747fdef9f6ac6271fda98a806654cb97e

Initialize `env_logger` for our `*.wast` tests

view details

Nick Fitzgerald

commit sha d3cf7d6255a13cbdbdb1d53295a50a43149ec817

cranelift_wasm: expose the original Wasm function signature In the `ModuleEnvironment::declare_signature` callback, also pass the original Wasm function signature, so that consumers may associate this information with each compiled function. This is often necessary because while each Wasm signature gets compiled down into a single native signature, multiple Wasm signatures might compile down into the same native signature, and in these cases the original Wasm signature is required for dynamic type checking of calls.

view details

Nick Fitzgerald

commit sha 8deafef2e37ed67d72e4314bb3307a9ace7f1063

Update `wasmparser` to 0.57.0

view details

Nick Fitzgerald

commit sha 14540eedcd3a575fbf969d9235e06b13d1eee9df

WIP: Initial, partial support for `externref`

view details

push time in 5 days

created tagbytecodealliance/wasm-tools

tagwasmparser-0.57.0

Low level tooling for WebAssembly in Rust

created time in 5 days

push eventbytecodealliance/wasm-tools

Nick Fitzgerald

commit sha 95089b82d48aba1bd559b5835d651bc000689821

wasmparser: bump to version 0.57.0

view details

push time in 5 days

push eventfitzgen/wasm-tools

Nick Fitzgerald

commit sha b022294e78ae86b6ace20243db7fdd78390ae937

wasmparser: Remove `form` member from `FuncType` It is only used to check that the `form` type is a `Type::Func`, which we can do at parse time, rather than keeping it around.

view details

Nick Fitzgerald

commit sha b822b16c458df9500a8ba11772ab552777b0f1e7

wasmparser: Implement `Eq` and `Hash` for `FuncType`

view details

Nick Fitzgerald

commit sha cba8123a618d1543c751753b8318127c74346dd4

Merge pull request #16 from fitzgen/remove-form wasmparser: Remove `form` member from `FuncType`

view details

Nick Fitzgerald

commit sha 95089b82d48aba1bd559b5835d651bc000689821

wasmparser: bump to version 0.57.0

view details

push time in 5 days

push eventfitzgen/wasm-tools

Nick Fitzgerald

commit sha d18b43581a6a4ab351bf837d21acd24859d61eb0

wasmparser: bump to version 0.56.0

view details

push time in 5 days

created tagbytecodealliance/wasm-tools

tagwasmparser-0.56.0

Low level tooling for WebAssembly in Rust

created time in 5 days

delete branch fitzgen/wasm-tools

delete branch : remove-form

delete time in 5 days

push eventbytecodealliance/wasm-tools

Nick Fitzgerald

commit sha b022294e78ae86b6ace20243db7fdd78390ae937

wasmparser: Remove `form` member from `FuncType` It is only used to check that the `form` type is a `Type::Func`, which we can do at parse time, rather than keeping it around.

view details

Nick Fitzgerald

commit sha b822b16c458df9500a8ba11772ab552777b0f1e7

wasmparser: Implement `Eq` and `Hash` for `FuncType`

view details

Nick Fitzgerald

commit sha cba8123a618d1543c751753b8318127c74346dd4

Merge pull request #16 from fitzgen/remove-form wasmparser: Remove `form` member from `FuncType`

view details

push time in 5 days

PR merged bytecodealliance/wasm-tools

wasmparser: Remove `form` member from `FuncType`

It is only used to check that the form type is a Type::Func, which we can do at parse time, rather than keeping it around.

+16 -16

0 comment

5 changed files

fitzgen

pr closed time in 5 days

push eventfitzgen/wasm-tools

Nick Fitzgerald

commit sha b822b16c458df9500a8ba11772ab552777b0f1e7

wasmparser: Implement `Eq` and `Hash` for `FuncType`

view details

push time in 5 days

PR opened bytecodealliance/wasm-tools

Reviewers
wasmparser: Remove `form` member from `FuncType`

It is only used to check that the form type is a Type::Func, which we can do at parse time, rather than keeping it around.

+15 -15

0 comment

5 changed files

pr created time in 5 days

create barnchfitzgen/wasm-tools

branch : remove-form

created branch time in 5 days

fork fitzgen/wasm-tools

Low level tooling for WebAssembly in Rust

fork in 5 days

startedbytecodealliance/wasm-tools

started time in 5 days

push eventbytecodealliance/wasmtime

whitequark

commit sha b2e8ed4dc9e360ed22c0d0ad97a287df8dbc37f3

cranelift: add i64.[us]{div,rem} libcalls. These libcalls are useful for 32-bit platforms.

view details

Nick Fitzgerald

commit sha 193f9c9e150387854ed616d7d2a5392f56462208

Merge pull request #1746 from whitequark/i64-divrem-libcalls cranelift: add i64.[us]{div,rem} libcalls

view details

push time in 5 days

PR merged bytecodealliance/wasmtime

cranelift: add i64.[us]{div,rem} libcalls cranelift cranelift:module

These libcalls are useful for 32-bit platforms, which do not have native 64-bit div/rem operations. The tests are similar to the existing ones in i64-arith.clif, but for i686.

+78 -0

1 comment

5 changed files

whitequark

pr closed time in 5 days

push eventfitzgen/wasmtime

Nick Fitzgerald

commit sha 2d896a26ead3b8d1efe71536aabc52ebd8f387ca

runtime: Introduce `VMExternRef` and `VMExternData` `VMExternRef` is a reference-counted box for any kind of data that is external and opaque to running Wasm. Sometimes it might hold a Wasmtime thing, other times it might hold something from a Wasmtime embedder and is opaque even to us. It is morally equivalent to `Rc<dyn Any>` in Rust, but additionally always fits in a pointer-sized word. `VMExternRef` is non-nullable, but `Option<VMExternRef>` is a null pointer. The one part of `VMExternRef` that can't ever be opaque to us is the reference count. Even when we don't know what's inside an `VMExternRef`, we need to be able to manipulate its reference count as we add and remove references to it. And we need to do this from compiled Wasm code, so it must be `repr(C)`! `VMExternRef` itself is just a pointer to an `VMExternData`, which holds the opaque, boxed value, its reference count, and its vtable pointer. The `VMExternData` struct is *preceded* by the dynamically-sized value boxed up and referenced by one or more `VMExternRef`s: ```ignore ,-------------------------------------------------------. | | V | +----------------------------+-----------+-----------+ | | dynamically-sized value... | ref_count | value_ptr |---' +----------------------------+-----------+-----------+ | VMExternData | +-----------------------+ ^ +-------------+ | | VMExternRef |-------------------+ +-------------+ | | +-------------+ | | VMExternRef |-------------------+ +-------------+ | | ... === | +-------------+ | | VMExternRef |-------------------' +-------------+ ``` The `value_ptr` member always points backwards to the start of the dynamically-sized value (which is also the start of the heap allocation for this value-and-`VMExternData` pair). Because it is a `dyn` pointer, it is fat, and also points to the value's `Any` vtable. The boxed value and the `VMExternRef` footer are held a single heap allocation. The layout described above is used to make satisfying the value's alignment easy: we just need to ensure that the heap allocation used to hold everything satisfies its alignment. It also ensures that we don't need a ton of excess padding between the `VMExternData` and the value for values with large alignment.

view details

push time in 6 days

create barnchfitzgen/wasmtime

branch : externref

created branch time in 6 days

push eventfitzgen/rust

bors

commit sha e91aebc1a3835b9b420da0c021e211175a724b8d

Auto merge of #71664 - Dylan-DPC:rollup-eng60x9, r=Dylan-DPC Rollup of 5 pull requests Successful merges: - #71217 (Suggest `;` or assignment to drop borrows in tail exprs) - #71286 (Add regression test for #69654) - #71296 (Change wording on read_vectored docs) - #71654 (Update link to unstable book for llvm_asm macro) - #71657 (Add #24949 assoc constant static recursion test) Failed merges: r? @ghost

view details

Ralf Jung

commit sha a03355dea0b7d042b8b4e01d75bba6c7489e3a14

some more test cases

view details

Ralf Jung

commit sha 07772fcf6fca44217439154aa37e4854dd5aef34

expand comment in memory.rs with extra soundness concerns

view details

flip1995

commit sha cd3480991a9078e2aa430ac09ab29dd19683b799

Rustup to rust-lang/rust#71518

view details

Bastian Kauschke

commit sha 827d6f6c3d4ea2b9c7dd64b76c05c2ca204f6b76

document stable counterparts of intrinsics

view details

bors

commit sha 36d13cb01ba6a0a9b7c13ca2b9461a111cb3e395

Auto merge of #67343 - ecstatic-morse:qualif-structural-match, r=pnkfelix Const qualification for `StructuralEq` Furthers #62411. Resolves #62614. The goal of this PR is to implement the logic in #67088 on the MIR instead of the HIR. It uses the `Qualif` trait to track `StructuralPartialEq`/`StructuralEq` in the final value of a `const`. Then, if we encounter a constant during HAIR lowering whose value may not be structurally matchable, we emit the `indirect_structural_match` lint. This PR contains all the tests present in #67088 and emits the proper warnings for the corner cases. This PR does not handle #65466, which would require that we be [more aggressive](https://github.com/rust-lang/rust/blob/42abbd8878d3b67238f3611b0587c704ba94f39c/src/librustc_mir_build/hair/pattern/const_to_pat.rs#L126-L130) when checking matched types for `PartialEq`. I think that should be done separately. Because this works on MIR and uses dataflow, this PR should accept more cases than #67088. Notably, the qualifs in the final value of a const are encoded cross-crate, so matching on a constant whose value is defined in another crate to be `Option::<TyWithCustomEqImpl>::None` should work. Additionally, if a `const` has branching/looping, we will only emit the warning if any possible control flow path could result in a type with a custom `PartialEq` impl ending up as the final value of a `const`. I'm not sure how #67088 handled this. AFAIK, it's not settled that these are the semantics we actually want: it's just how the `Qualif` framework happens to work. If the cross-crate part is undesirable, it would be quite easy to change the result of `mir_const_qualif().custom_eq` to `true` before encoding it in the crate metadata. This way, other crates would have to assume that all publicly exported constants may not be safe for matching. r? @pnkfelix cc @eddyb

view details

bors

commit sha 28197b622611ba3a6367648974ccf59127c287bb

Auto merge of #5545 - flip1995:rustup, r=flip1995 Rustup to rust-lang/rust#71518 changelog: none

view details

flip1995

commit sha 891b0e2dffceb77933e88ab34647f3c2316c1ec9

Update Clippy

view details

Donough Liu

commit sha a9858791134253d004971664fd7e9bd9b0983723

Suggest deref when coercing `ty::Ref` to `ty::RawPtr`

view details

Pietro Albini

commit sha fde5811d7403f1e1f0ff5ccf1d1d0516d6d3c966

ci: use bash when executing the "bors build finished" jobs We don't clone the repository in those builders, so the default shell (src/ci/exec-with-shell.py) is not present there.

view details

Mark Rousskov

commit sha cf5e4a749c13d3a472a6aed4097df5dc90194057

Add explicit references to the BuildHasher trait

view details

Eric Huss

commit sha d6336dfe01744209b1aa0987c0a7a6c1d79a8ff4

Add an index page for nightly rustc docs.

view details

Mark Rousskov

commit sha a1f81ff0ad112d1d8e1ce86df1feb8abcdac76b6

rustdoc supports const re-exports

view details

Nicholas Bishop

commit sha f408a4e9bdfae6334a26f169d4502156cf469056

Fix doc link to Eq trait from PartialEq trait The `Eq` link was incorrectly going to the `eq` method of `PartialEq` instead of to the `Eq` trait.

view details

Eric Huss

commit sha 1776de948cc26652b8e4fd383bb8fbf05d0ab727

Bump pulldown-cmark

view details

bors

commit sha c50bd7e40284839bd0a094be67c48528aeecacb0

Auto merge of #71674 - flip1995:clippyup, r=Dylan-DPC Update Clippy Fixes #71608

view details

Ralf Jung

commit sha a430bd5549dfeced82f8ef5b6bfe36e7f6780ad1

update Miri

view details

Bastian Kauschke

commit sha 9f34b82de203a01b7bb1afd57714886a65dbea8f

forbid `dyn Trait` in const generics

view details

Dylan MacKenzie

commit sha bd8a6d79116bdefde629c22693cdd8e87ad7cc72

Allow `Downcast` projections unconditionally

view details

Bastian Kauschke

commit sha 2f5c0f59a96612667ca6aeb40b6e40259f861e7e

emit err when using trait objects in pat

view details

push time in 7 days

push eventfitzgen/wasmtime

Benjamin Bouvier

commit sha 1f620e1b465c09a7d7bfd22288d454ef81e35e08

cranelift: bump regalloc.rs to 0.0.24 and adapt to latest API changes;

view details

Nick Fitzgerald

commit sha f28b3738ee23850d18696bd7230a6eee7da283ac

Rename `anyref` to `externref` across the board

view details

Jakub Konka

commit sha 348be6f3ed7c52bf9038e49a04da3aa89d0f56f7

Revert fstatat on *nix and test symlinks in path_filestat calls (#1725) * Revert fstatat on *nix and test symlinks in path_filestat calls This commit effectively reverts too eager refactoring on my part which resulted in incorrect `path_filestat_{get, set_times}` behaviour on *nix hosts. In the presence of symlinks, neither of the calls would work properly. In order to shield ourselves from similar errors in the future, I've augmented the `path_filestat` test cases with symlink checks as well. * Pass appropriate flags to fstatat and utimensat * Fix formatting * Fix Windows build * Expand final symlinks if follow is set on Windows * Fix formatting * Do not follow symlinks unless specified on Windows * Update comments and restart CI * Skip testing volatile atim field

view details

Nick Fitzgerald

commit sha e229fbc79c43071675cb6fb68963241f1b38c70d

Merge pull request #1733 from fitzgen/rename-anyref-to-externref Rename `anyref` to `externref` across the board

view details

push time in 7 days

delete branch fitzgen/wasmtime

delete branch : rename-anyref-to-externref

delete time in 7 days

push eventbytecodealliance/wasmtime

Nick Fitzgerald

commit sha f28b3738ee23850d18696bd7230a6eee7da283ac

Rename `anyref` to `externref` across the board

view details

Nick Fitzgerald

commit sha e229fbc79c43071675cb6fb68963241f1b38c70d

Merge pull request #1733 from fitzgen/rename-anyref-to-externref Rename `anyref` to `externref` across the board

view details

push time in 7 days

PR merged bytecodealliance/wasmtime

Rename `anyref` to `externref` across the board fuzzing wasmtime:api wasmtime:c-api
+151 -130

1 comment

25 changed files

fitzgen

pr closed time in 7 days

issue closedgoogle/oss-fuzz

Is running fuzz targets on aarch64 supported?

I searched the docs and found no references to aarch64, but did see a couple commits/issues mentioning it, and I wasn't able to determine whether running fuzz targets on aarch64 is supported or not. And if it is supported, it isn't clear to me how to set it up.

We recently added aarch64 support to Wasmtime and its compiler, Cranelift, and would love to fuzz the new compiler backend and runtime.

Thanks for your time!

cc @bnjbvr

closed time in 7 days

fitzgen

issue commentgoogle/oss-fuzz

Is running fuzz targets on aarch64 supported?

Ok, thanks for the info!

fitzgen

comment created time in 7 days

push eventfitzgen/wasmtime

Nick Fitzgerald

commit sha f28b3738ee23850d18696bd7230a6eee7da283ac

Rename `anyref` to `externref` across the board

view details

push time in 7 days

create barnchfitzgen/wasmtime

branch : rename-anyref-to-externref

created branch time in 7 days

push eventfitzgen/wasmtime

Chris Fallin

commit sha 72e6be9342d294da2ecb526aa92959a8bec9c402

Rework of MachInst isel, branch fixups and lowering, and block ordering. This patch includes: - A complete rework of the way that CLIF blocks and edge blocks are lowered into VCode blocks. The new mechanism in `BlockLoweringOrder` computes RPO over the CFG, but with a twist: it merges edge blocks intto heads or tails of original CLIF blocks wherever possible, and it does this without ever actually materializing the full nodes-plus-edges graph first. The backend driver lowers blocks in final order so there's no need to reshuffle later. - A new `MachBuffer` that replaces the `MachSection`. This is a special version of a code-sink that is far more than a humble `Vec<u8>`. In particular, it keeps a record of label definitions and label uses, with a machine-pluggable `LabelUse` trait that defines various types of fixups (basically internal relocations). Importantly, it implements some simple peephole-style branch rewrites *inline in the emission pass*, without any separate traversals over the code to use fallthroughs, swap taken/not-taken arms, etc. It tracks branches at the tail of the buffer and can (i) remove blocks that are just unconditional branches (by redirecting the label), (ii) understand a conditional/unconditional pair and swap the conditional polarity when it's helpful; and (iii) remove branches that branch to the fallthrough PC. The `MachBuffer` also implements branch-island support. On architectures like AArch64, this is needed to allow conditional branches within plausibly-attainable ranges (+/- 1MB on AArch64 specifically). It also does this inline while streaming through the emission, without any sort of fixpoint algorithm or later moving of code, by simply tracking outstanding references and "deadlines" and emitting an island just-in-time when we're in danger of going out of range. - A rework of the instruction selector driver. This is largely following the same algorithm as before, but is cleaned up significantly, in particular in the API: the machine backend can ask for an input arg and get any of three forms (constant, register, producing instruction), indicating it needs the register or can merge the constant or producing instruction as appropriate. This new driver takes special care to emit constants right at use-sites (and at phi inputs), minimizing their live-ranges, and also special-cases the "pinned register" to avoid superfluous moves. Overall, on `bz2.wasm`, the results are: wasmtime full run (compile + runtime) of bz2: baseline: 9774M insns, 9742M cycles, 3.918s w/ changes: 7012M insns, 6888M cycles, 2.958s (24.5% faster, 28.3% fewer insns) clif-util wasm compile bz2: baseline: 2633M insns, 3278M cycles, 1.034s w/ changes: 2366M insns, 2920M cycles, 0.923s (10.7% faster, 10.1% fewer insns) All numbers are averages of two runs on an Ampere eMAG.

view details

Chris Fallin

commit sha 687aca00fe77fb657de05299df4e422d99f0b2c5

Update x64 backend to use new lowering APIs.

view details

Chris Fallin

commit sha bdd2873c8ce3eb48caf58c2f4921537e270e0dc9

Address review comments.

view details

Nick Fitzgerald

commit sha 28d6df0db6df0dc083eaea6b29b8fe1773eef5ff

Limit the size of automaton keys in the `peepmatic_fst_diff` fuzz target (#1724) This should avoid timeouts caused by large keys. Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=22251

view details

Chris Fallin

commit sha d8d6fbe58c41e33477fd21df954ab87d864c16c0

Merge pull request #1718 from cfallin/machinst-codebuffer Rework of MachInst isel, branch fixups and lowering, and block ordering.

view details

Nick Fitzgerald

commit sha 9d2100e54a137c79943cf991a9f7b07b011177e2

Limit the size of automaton keys in the `peepmatic_simple_automata` fuzz target Fixes https://oss-fuzz.com/testcase-detail/5742905129172992

view details

Nick Fitzgerald

commit sha 26e06297957bbc06b3244bc96d2e92b4246e8d9b

Merge pull request #1726 from fitzgen/fix-simple-automata-timeout Limit the size of automaton keys in the `peepmatic_simple_automata` fuzz target

view details

Nick Fitzgerald

commit sha 5c39b74eb8d6ff00262dc7579e462f1f61a809c8

Make the fuzzing CI job faster (#1727) * CI: Only build fuzz targets, don't run them over the corpora We've only ever caught a single potential regression by running the fuzz targets over a sample of their corpora. However, this is also our slowest CI job. Running the fuzz targets over their corpora simply isn't paying for itself. Instead, just ensure that we can build the fuzz targets with `cargo fuzz` and all of the libFuzzer and sanitizer instrumentation that it enables. This will ensure that we don't break the fuzz targets, and we leave finding regressions in the fuzz corpora to oss-fuzz. * fuzz: feature gate peepmatic's fuzz targets This makes it so that the CI's fuzz target-building job doesn't build peepmatic, and transitively Z3.

view details

push time in 7 days

issue openedgoogle/oss-fuzz

Is running fuzz targets on aarch64 supported?

I searched the docs and found no references to aarch64, but did see a couple commits/issues mentioning it, and I wasn't able to determine whether running fuzz targets on aarch64 is supported or not. And if it is supported, it isn't clear to me how to set it up.

We recently added aarch64 support to Wasmtime and its compiler, Cranelift, and would love to fuzz the new compiler backend and runtime.

Thanks for your time!

cc @bnjbvr

created time in 7 days

push eventfitzgen/z3.rs

ksqsf

commit sha 7b451960c4993ba2f3652f625ff45452d0e79650

add debug! for Solver::assert and assert_and_track

view details

Nick Fitzgerald

commit sha 6823c8d50a0f412da69d05585de44341ee334b2c

Merge pull request #78 from ksqsf/master Add debug! for Solver::assert and assert_and_track

view details

Nick Fitzgerald

commit sha e420d9be2ea96371a5fe7e6f671a91ca41773816

Tweak debug logging messages

view details

push time in 7 days

push eventprove-rs/z3.rs

Nick Fitzgerald

commit sha e420d9be2ea96371a5fe7e6f671a91ca41773816

Tweak debug logging messages

view details

push time in 7 days

push eventprove-rs/z3.rs

ksqsf

commit sha 7b451960c4993ba2f3652f625ff45452d0e79650

add debug! for Solver::assert and assert_and_track

view details

Nick Fitzgerald

commit sha 6823c8d50a0f412da69d05585de44341ee334b2c

Merge pull request #78 from ksqsf/master Add debug! for Solver::assert and assert_and_track

view details

push time in 7 days

PR merged prove-rs/z3.rs

Add debug! for Solver::assert and assert_and_track

This PR makes the debugging output a bit more helpful for library users.

Fix #77.

+2 -0

0 comment

1 changed file

ksqsf

pr closed time in 7 days

issue closedprove-rs/z3.rs

Debugging?

Hi,

I'm generating some assertions, but z3 complains type errors. I wanted to print out the details of the context. For example, print the SMTLib2 format. But z3-rs seems to have no support for any kind of inspection? I'd like to know what to do in this case...

I'm not familiar with z3-rs or z3-c++, so please forgive me if I make any mistakes.

closed time in 7 days

ksqsf

delete branch fitzgen/gimli

delete branch : fuzzing

delete time in 7 days

push eventgimli-rs/gimli

Nick Fitzgerald

commit sha f831aa18459ea9863b2c98eb30354f9c794f6d7b

Introduce a fuzz target for `.debug_info` and `.debug_abbrev`

view details

Nick Fitzgerald

commit sha 113e92664a5060845349f22b98b266ed1992a7cc

Introduce a fuzz target for `.debug_abbrev`

view details

Nick Fitzgerald

commit sha 80aa089011d43269fddcbef857dc49ef03c17bfa

Introduce a fuzz target for `.debug_line`

view details

Nick Fitzgerald

commit sha 32d1fdb1face46249ef725daab224c002f9e7743

Introduce a fuzz target for `.eh_frame` sections

view details

Nick Fitzgerald

commit sha ba8d6d670aab6e16473fb3cbd56b64d016c34e31

Introduce a fuzz target for `.debug_aranges`

view details

Nick Fitzgerald

commit sha 8eaea42e59c2a4b4ec35271027ee0641118497b5

tests: Add a self-parse test for `.eh_frame_hdr` sections

view details

Nick Fitzgerald

commit sha f4a7749d04c4cee6b66a80c23b912f92cfb0f3f5

Introduce a fuzz target for `.eh_frame_hdr`

view details

Nick Fitzgerald

commit sha c81ecb6e4aa9b12dda9161ed0e0e392c979c0666

Add contributing docs about our fuzzing setup

view details

Nick Fitzgerald

commit sha b7d1a194c6c4742f69ee77f3c0e3afb532fa84ab

CI: build and run our fuzz targets This builds them in one job, and then spawns N parallel jobs to run each built fuzz target for five minutes.

view details

Nick Fitzgerald

commit sha ea707d784e1a695255f049489a49c9f2f6cb6abc

Merge pull request #512 from fitzgen/fuzzing Add fuzzing infrastructure

view details

push time in 7 days

PR merged gimli-rs/gimli

Add fuzzing infrastructure

This adds a few fuzz targets for various DWARF sections, and also integrates it with our CI, so that the fuzz targets are built in one job, and then each fuzz target is run in N parallel jobs for five minutes.

The CI integration bits will likely involve a few tries and force pushes >.<

+268 -0

1 comment

12 changed files

fitzgen

pr closed time in 7 days

pull request commentgimli-rs/gimli

Add fuzzing infrastructure

Ok, I think this is good to go now!

fitzgen

comment created time in 8 days

push eventfitzgen/gimli

Nick Fitzgerald

commit sha b7d1a194c6c4742f69ee77f3c0e3afb532fa84ab

CI: build and run our fuzz targets This builds them in one job, and then spawns N parallel jobs to run each built fuzz target for five minutes.

view details

push time in 8 days

delete branch fitzgen/wasmtime

delete branch : fuzz-ci-job-faster

delete time in 8 days

push eventfitzgen/gimli

Nick Fitzgerald

commit sha 4496813f9b23ce292f233f9349d9121b7bfe4a26

CI: build and run our fuzz targets This builds them in one job, and then spawns N parallel jobs to run each built fuzz target for five minutes.

view details

push time in 8 days

push eventfitzgen/gimli

Nick Fitzgerald

commit sha b8a02df6c81f67e3b8ec8ca00709607159bf6dfe

CI: build and run our fuzz targets This builds them in one job, and then spawns N parallel jobs to run each built fuzz target for five minutes.

view details

push time in 8 days

push eventfitzgen/gimli

Nick Fitzgerald

commit sha 26182ada802b9c2bc8a47882544cedd249eade51

CI: build and run our fuzz targets This builds them in one job, and then spawns N parallel jobs to run each built fuzz target for five minutes.

view details

push time in 8 days

push eventfitzgen/gimli

Nick Fitzgerald

commit sha b96d670c3b41b9e20d4b8d5909364169faabef81

CI: build and run our fuzz targets This builds them in one job, and then spawns N parallel jobs to run each built fuzz target for five minutes.

view details

push time in 8 days

push eventfitzgen/gimli

Nick Fitzgerald

commit sha a555bbaf985c69f3a79b1622a70e62dae7a7da8b

CI: build and run our fuzz targets This builds them in one job, and then spawns N parallel jobs to run each built fuzz target for five minutes.

view details

push time in 8 days

push eventfitzgen/gimli

Nick Fitzgerald

commit sha c8389d48d7a5a9ead7448f36f1236f3970f02990

CI: build and run our fuzz targets This builds them in one job, and then spawns N parallel jobs to run each built fuzz target for five minutes.

view details

Nick Fitzgerald

commit sha 053b18e1dc725e9ba99b48deb1b4060687bfb33f

TEMP debugging CI

view details

push time in 8 days

push eventfitzgen/gimli

Nick Fitzgerald

commit sha f9ad82f9ee4c41518c20b39144396f7fb5618c2e

TEMP debugging ci

view details

push time in 8 days

push eventfitzgen/gimli

Nick Fitzgerald

commit sha 236ab003bebdc8419cc08bf6d5b659fe2b39362b

TEMP debugging ci

view details

push time in 8 days

PR opened gimli-rs/gimli

Reviewers
Add fuzzing infrastructure

This adds a few fuzz targets for various DWARF sections, and also integrates it with our CI, so that the fuzz targets are built in one job, and then each fuzz target is run in N parallel jobs for five minutes.

The CI integration bits will likely involve a few tries and force pushes >.<

+255 -0

0 comment

12 changed files

pr created time in 8 days

create barnchfitzgen/gimli

branch : fuzzing

created branch time in 8 days

delete branch fitzgen/oss-fuzz

delete branch : patch-1

delete time in 8 days

push eventgimli-rs/gimli-libfuzzer-corpora

Nick Fitzgerald

commit sha a7ee0766fbae852516eb19538637633892f72806

Add initial corpora

view details

push time in 8 days

create barnchgimli-rs/gimli-libfuzzer-corpora

branch : master

created branch time in 8 days

created repositorygimli-rs/gimli-libfuzzer-corpora

libFuzzer corpora for gimli's fuzz targets

created time in 8 days

pull request commentbytecodealliance/wasmtime

Make the fuzzing CI job faster

Related oss-fuzz change, to make sure it continues to build+run peepmatic fuzz targets: https://github.com/google/oss-fuzz/pull/3850

fitzgen

comment created time in 8 days

PR opened google/oss-fuzz

wasmtime: build fuzz targets with --all-features

This enables not only the binaryen-using fuzz targets, but also the peepmatic fuzz targets (which is necessary after https://github.com/bytecodealliance/wasmtime/pull/1727).

+4 -1

0 comment

1 changed file

pr created time in 8 days

push eventfitzgen/oss-fuzz

Nick Fitzgerald

commit sha af87a754b22f6df6e1b34732e31051ccb3904f88

wasmtime: build fuzz targets with --all-features This enables not only the binaryen-using fuzz targets, but also the peepmatic fuzz targets (which is necessary after https://github.com/bytecodealliance/wasmtime/pull/1727).

view details

push time in 8 days

PR opened bytecodealliance/wasmtime

Reviewers
Make the fuzzing CI job faster
  • Don't run a sample of the fuzz corpora in CI anymore; it isn't worth it.

  • Feature gate peepmatic fuzz targets, and don't build them in the fuzz CI job (they are one liners that call functions defined in peepmatic-fuzzing which we already check in the peepmatic job).

+13 -83

0 comment

2 changed files

pr created time in 8 days

create barnchfitzgen/wasmtime

branch : fuzz-ci-job-faster

created branch time in 8 days

delete branch fitzgen/wasmtime

delete branch : fix-simple-automata-timeout

delete time in 8 days

push eventbytecodealliance/wasmtime

Nick Fitzgerald

commit sha 9d2100e54a137c79943cf991a9f7b07b011177e2

Limit the size of automaton keys in the `peepmatic_simple_automata` fuzz target Fixes https://oss-fuzz.com/testcase-detail/5742905129172992

view details

Nick Fitzgerald

commit sha 26e06297957bbc06b3244bc96d2e92b4246e8d9b

Merge pull request #1726 from fitzgen/fix-simple-automata-timeout Limit the size of automaton keys in the `peepmatic_simple_automata` fuzz target

view details

push time in 8 days

PR merged bytecodealliance/wasmtime

Limit the size of automaton keys in the `peepmatic_simple_automata` fuzz target cranelift cranelift:area:peepmatic

Fixes https://oss-fuzz.com/testcase-detail/5742905129172992

+15 -5

3 comments

1 changed file

fitzgen

pr closed time in 8 days

pull request commentbytecodealliance/wasmtime

Limit the size of automaton keys in the `peepmatic_simple_automata` fuzz target

The link is not publicly accessible.

That is correct. Fuzz bugs aren't public because they may be security bugs. They get auto-disclosed after 90 days.

In this case, it was just a timeout, where the fuzz target took longer than 60s to run.

fitzgen

comment created time in 8 days

PR opened bytecodealliance/wasmtime

Reviewers
Limit the size of automaton keys in the `peepmatic_simple_automata` fuzz target

Fixes https://oss-fuzz.com/testcase-detail/5742905129172992

+15 -5

0 comment

1 changed file

pr created time in 8 days

push eventfitzgen/wasmtime

Nick Fitzgerald

commit sha 9d2100e54a137c79943cf991a9f7b07b011177e2

Limit the size of automaton keys in the `peepmatic_simple_automata` fuzz target Fixes https://oss-fuzz.com/testcase-detail/5742905129172992

view details

push time in 8 days

create barnchfitzgen/wasmtime

branch : fix-simple-automata-timeout

created branch time in 8 days

issue commentprove-rs/z3.rs

Debugging?

I would be happy to merge a PR that added debug-level logging of assertions given to a context in the z3::Solver::assert and z3::Solver::assert_and_track methods, if you would like to implement it.

ksqsf

comment created time in 8 days

delete branch fitzgen/wasmtime

delete branch : fix-fst-differential-timeout

delete time in 8 days

delete branch fitzgen/gimli

delete branch : switch-from-travis-to-github-actions

delete time in 8 days

push eventgimli-rs/gimli

Nick Fitzgerald

commit sha 88579af68f2fae83a79d55b62910126895d89da2

github actions: Also cross compile+test for a big-endian target

view details

Nick Fitzgerald

commit sha 6c41f7cfd700d734cea3dcbf7c96b90c0bd7eb4c

Remove Travis CI; Switch to Github Actions Previous commits set up an initial install of github actions, this commit is mostly removing Travis CI. Note that it does not completely remove Travis CI, since our coverage job is not fully ported over yet. We do run the coverage job in github actions, but don't upload it anywhere, currently. So for now, Travis CI is still enabled, but only runs the coverage job and uploads the results to coveralls.io.

view details

Nick Fitzgerald

commit sha 08f36f01a0ad8fbf68ebc5be802b44a805ab43c2

Merge pull request #511 from fitzgen/switch-from-travis-to-github-actions Switch from Travis CI to GitHub Actions

view details

push time in 8 days

PR merged gimli-rs/gimli

Switch from Travis CI to GitHub Actions

Technically, I already created an initial github actions install, because it won't run CI until you've merged it into the master branch and that involves the inevitable config tweaking: https://github.com/gimli-rs/gimli/blob/master/.github/workflows/rust.yml

Github actions gives us ten parallel jobs at the free, open source tier, while travis only gives us two now. I also removed a few of the redundant matrix combinations. The result is that CI is way faster now. I don't have actual numbers, but I'm pretty sure we were at at least a half hour before, and it is probably ten minutes or so now.

+10 -103

3 comments

4 changed files

fitzgen

pr closed time in 8 days

pull request commentgimli-rs/gimli

Switch from Travis CI to GitHub Actions

I'm going to go ahead and merge this now, and leave the final migration of the coverage job from travis to github actions for later.

fitzgen

comment created time in 8 days

pull request commentgimli-rs/gimli

Switch from Travis CI to GitHub Actions

FYI, I recently changed coveralls to only use the status API (instead of comments) to reduce the spam. It makes it less visible though, and even more so with this number of actions, but I think it's still ok? It's also configured to never fail, which may not be the best...

I didn't really mind the spam, but I don't really care either way.

fitzgen

comment created time in 8 days

Pull request review commentgimli-rs/gimli

Switch from Travis CI to GitHub Actions

 before_script: - echo PATH is $PATH - export RUST_BACKTRACE=1 -script: ./ci/script.sh--env:-  matrix:-    - GIMLI_JOB="test"-    - GIMLI_JOB="features"--matrix:-  fast_finish: true-  include:-    # Coverage should only run on Linux. tarpaulin currently requires nightly Rust.-    - rust: nightly-      os: linux-      sudo: required-      env: GIMLI_JOB="coverage"-    # Building docs only needs to happen on one os and only on stable.-    - rust: stable-      os: linux-      env: GIMLI_JOB="doc"-    # Benching should only happen on nightly.-    - rust: nightly-      env: GIMLI_JOB="bench"-    # Build a 32 bit target.-    - rust: stable-      sudo: required-      services: docker-      env:-        - TARGET=i686-unknown-linux-gnu-        - GIMLI_JOB=cross-    # Build a big-endian target.-    - rust: stable-      sudo: required-      services: docker-      env:-        - TARGET=powerpc64-unknown-linux-gnu-        - GIMLI_JOB=cross+script: |+  RUSTFLAGS="--cfg procmacro2_semver_exempt" cargo install cargo-tarpaulin+  cargo tarpaulin --verbose --ciserver travis-ci --coveralls "$TRAVIS_JOB_ID"

Nope, just because I haven't looked into how to configure cargo tarpaulin and github actions together, nor added a token for them to talk to each other.

fitzgen

comment created time in 8 days

Pull request review commentgimli-rs/gimli

Switch from Travis CI to GitHub Actions

-sudo: false+sudo: required

We were using it for the coverage job before, and this just carries that over. I have no idea if it is actually required or not.

fitzgen

comment created time in 8 days

delete branch fitzgen/gimli

delete branch : overflows-and-div-by-zero-in-debug-aranges

delete time in 8 days

push eventgimli-rs/gimli

Nick Fitzgerald

commit sha 2c2dc79c2c4461e241a8457598e96a9ba7974b26

Handle overflow in `.debug_aranges` headers

view details

Nick Fitzgerald

commit sha 74b8ebecbf3725146baa2599f60fca9d36ce7d84

Avoid division by zero when parsing `.debug_aranges` headers

view details

Nick Fitzgerald

commit sha 33ea78635c12078ae68beac0240653a7d56c24e7

Merge pull request #510 from fitzgen/overflows-and-div-by-zero-in-debug-aranges Fix some overflows and division-by-zero in `.debug_aranges` handling

view details

push time in 8 days

Pull request review commentgimli-rs/gimli

Fix some overflows and division-by-zero in `.debug_aranges` handling

 impl<R: Reader> LookupParser<R> for ArangeParser<R> {         // The first tuple following the header in each set begins at an offset that is         // a multiple of the size of a single tuple (that is, the size of a segment selector         // plus twice the size of an address).-        let tuple_length = 2 * address_size + segment_size;+        let tuple_length = address_size+            .checked_mul(2)+            .and_then(|x| x.checked_add(segment_size))+            .ok_or(Error::InvalidAddressRange)?;

Yeah, the error variant's name is sort of relevant, but the display isn't. But it also didn't feel like this deserved its own new variant.

fitzgen

comment created time in 8 days

PR opened bytecodealliance/wasmtime

Reviewers
Limit the size of automaton keys in the `peepmatic_fst_diff` fuzz target

This should avoid timeouts caused by large keys.

Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=22251

+5 -1

0 comment

1 changed file

pr created time in 9 days

create barnchfitzgen/wasmtime

branch : fix-fst-differential-timeout

created branch time in 9 days

push eventfitzgen/wasmtime

Nick Fitzgerald

commit sha 9b867b09c7a94f017ad9c77a143d831315dd0228

cranelift: Sign extend `Imm64` immediates When an instruction has an `Imm64` immediate, but operates on values of a narrower width, we need to sign extend the value. Fixes #1095

view details

Joey Gouly

commit sha f418b7a7006842437e75a584e353cdd6fc59d93d

Reduce arm64 Inst enum size This reduces the size of the Inst enum from 112 bytes to 48 bytes. Using DHAT on a regex-rs.wasm benchmark, `valgrind --tool=dhat clif-util compile --target aarch64` The total number of allocated bytes, drops by around 170 MB. At t-gmax drops by 3 MB. Using `perf stat clif-util compile --target aarch64`, the instructions count dropped by 0.6%. Cache misses dropped by 6%. Cycles dropped by 2.3%.

view details

Nick Fitzgerald

commit sha 98137ea09f6bb1e00fa02eedf1fdc5216215a0d4

Add github labels actions integration for peepmatic

view details

Nick Fitzgerald

commit sha fb7a690efc6ba41dae4eb51994ec2db835443997

Merge pull request #1687 from fitzgen/sign-extend-immediates cranelift: Sign extend `Imm64` immediates

view details

Nick Fitzgerald

commit sha 27d3bf9aee3a510a7ba3ff5539a7f877283e6b35

Merge pull request #1701 from fitzgen/peepmatic-github-actions Add github labels actions integration for peepmatic

view details

Nick Fitzgerald

commit sha e9ef8ea3d59eac0123c727cd6f666b0c7c1b06ce

peepmatic: remove unused member from `PeepholeOptimizer` This is dead code, left over from an earlier design.

view details

Nick Fitzgerald

commit sha 3c0b64fef7fa6b670c53b5178d7a33eb13cf8d78

Merge pull request #1710 from fitzgen/remove-unused-lhs-member peepmatic: remove unused member from `PeepholeOptimizer`

view details

Nick Fitzgerald

commit sha 1a4f3fb2df0b8b177fb9c830cf740776bd685f03

Update deps and tests for `anyref` --> `externref` * Update to using `wasmparser` 0.55.0 * Update wasmprinter to 0.2.5 * Update `wat` to 1.0.18, and `wast` to 17.0.0

view details

Chris Fallin

commit sha df4028749e53d0da258a5e6c5d3779414440130b

Merge pull request #1699 from jgouly/inst-size Reduce arm64 Inst enum size

view details

Nick Fitzgerald

commit sha 01f46d02383be038465d86d5c2e22e2d2454d3ec

Merge pull request #1692 from fitzgen/update-to-wasmparser-0.55.0 Update to using `wasmparser` 0.55.0

view details

Johnnie Birch

commit sha 2c00aef88a3b0044e5dd3b6c663290a493f3e4fe

Automatically label PRs related to the new x64 backend

view details

Pat Hickey

commit sha c36a214ce746bdeceada0136e2f0141ccda4761d

Merge pull request #1711 from jlb6740/label_for_x64 Automatically label PRs related to the new x64 backend

view details

Y-Nak

commit sha 0393d101b1ede19a087f51fcd3111be1782384ce

Fix typo in peepmatic (#1712)

view details

Alex Crichton

commit sha 8f2d442ffd852d40f128b4c00830279aad894e09

Remove dependabot from wasmtime (#1713) Right now we're just getting a lot of noisy "can't parse manifest" error messages, and with `cargo audit` running on CI we should be alerted to security vulnerabilities anyway.

view details

Alex Crichton

commit sha bd0b8189002a773b27eb539168be4fe8c08ddc4d

Default to using `bash` on Github Actions (#1591) This updates our github actions configuration with a new feature released which allows configuring the default shell for the entire worflow. Here we set that to `bash` since we frequently do that anyway and it helps keep syntax consistent throughout the configuration file.

view details

Nick Fitzgerald

commit sha 463734b002f2df457c383a009fddedf0156d08e4

CI: only test `peepmatic` in one job (#1714) * CI: only test `peepmatic` in one job This avoids building Z3 in most jobs, which saves CI time. * Fix curl syntax on Windows Co-authored-by: Alex Crichton <alex@alexcrichton.com>

view details

Austin Abell

commit sha e40fd9d6ab8a82913f1e39b598c3d9e0e3095224

Fix Wasm from rust docs (#1719) * Update Wasm from Rust docs * oops * oops x2

view details

Alex Crichton

commit sha f22f415b148b236afa2de4117c0fb2cf22da33e0

Document cross-compiling Wasmtime (#1721) Closes #1720

view details

Chris Fallin

commit sha 6e8666826dd7bb53c80e1bcfd63fb958defab88b

Docs: add section on running under qemu.

view details

Chris Fallin

commit sha a75377565f830052094aa8aa72c5e7a6b787fa18

Merge pull request #1722 from cfallin/docs-qemu-run Docs: add section on running under qemu.

view details

push time in 9 days

push eventfitzgen/gimli

Nick Fitzgerald

commit sha 6c41f7cfd700d734cea3dcbf7c96b90c0bd7eb4c

Remove Travis CI; Switch to Github Actions Previous commits set up an initial install of github actions, this commit is mostly removing Travis CI. Note that it does not completely remove Travis CI, since our coverage job is not fully ported over yet. We do run the coverage job in github actions, but don't upload it anywhere, currently. So for now, Travis CI is still enabled, but only runs the coverage job and uploads the results to coveralls.io.

view details

push time in 9 days

PR opened gimli-rs/gimli

Reviewers
Switch from Travis CI to GitHub Actions

Technically, I already created an initial github actions install, because it won't run CI until you've merged it into the master branch and that involves the inevitable config tweaking: https://github.com/gimli-rs/gimli/blob/master/.github/workflows/rust.yml

Github actions gives us ten parallel jobs at the free, open source tier, while travis only gives us two now. I also removed a few of the redundant matrix combinations. The result is that CI is way faster now. I don't have actual numbers, but I'm pretty sure we were at at least a half hour before, and it is probably ten minutes or so now.

+10 -103

0 comment

4 changed files

pr created time in 9 days

create barnchfitzgen/gimli

branch : switch-from-travis-to-github-actions

created branch time in 9 days

push eventgimli-rs/gimli

Nick Fitzgerald

commit sha 6d3ca24905aed795dd26d3e6fc12eb6203b19c94

github actions: Use nightly for `cargo bench` job

view details

push time in 9 days

push eventgimli-rs/gimli

Nick Fitzgerald

commit sha 73c7cede18dea332d80d26f115b1c25cdab6922f

github actions: fix rustup installation

view details

push time in 9 days

push eventgimli-rs/gimli

Nick Fitzgerald

commit sha a442edebe771bf05d8c2cc57394d6c66526c58b0

github actions: fix os-conditional step runs

view details

push time in 9 days

push eventgimli-rs/gimli

Nick Fitzgerald

commit sha 44183f4ffaed4e73699413e4c9774aa855815fb0

github actions: fix references to `rust_channel` variable Use `${{matrix.rust_channel}}` not plain `{{rust_channel}}`.

view details

push time in 9 days

push eventgimli-rs/gimli

Nick Fitzgerald

commit sha ffa4596ad18ef411460cc1e850e8af8ae90528af

Add initial github actions CI

view details

push time in 9 days

create barnchfitzgen/gimli

branch : overflows-and-div-by-zero-in-debug-aranges

created branch time in 9 days

delete branch fitzgen/gimli

delete branch : debug-line-wrap-overflows

delete time in 9 days

push eventgimli-rs/gimli

Nick Fitzgerald

commit sha 2b2308904c47b591be4451b4b6d8490edee92667

Let arithmetic overflows wrap when executing line programs The DWARF spec isn't clear on how to handle overflow, but there is a small chance some random toolchain in the wild relies on overflow to do hacky subtraction of the current row's address. And wrapping is faster than checking for overflow and returning an error anyways. So we just do wrapping. /me shrugs Fixes #506

view details

Nick Fitzgerald

commit sha 1ff72fe7f12ae63cfaffcfd7e838c3bc6d90b04f

Merge pull request #508 from fitzgen/debug-line-wrap-overflows Let arithmetic overflows wrap when executing line programs

view details

push time in 9 days

PR merged gimli-rs/gimli

Let arithmetic overflows wrap when executing line programs

The DWARF spec isn't clear on how to handle overflow, but there is a small chance some random toolchain in the wild relies on overflow to do hacky subtraction of the current row's address. And wrapping is faster than checking for overflow and returning an error anyways. So we just do wrapping.

/me shrugs

Fixes #506

+75 -40

5 comments

1 changed file

fitzgen

pr closed time in 9 days

more