You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
THIS MESSAGE WAS GENERATED BY AN AUTOMATED PROCESS
Problem
PyVEX's Thumb regressions need a real instruction stream that combines a mixed 16/32/16-bit ITTT group, a false 0xbf08 IT candidate inside LDREX, and the nine-halfword lookback edge. Binaries master has no tests/armel/thumb_it_lookback_widths.bin.
Root cause
The lookback decision depends on actual Thumb instruction widths and alignment. Synthetic bytes in the consumer test would bypass the workspace's real-fixture policy and would not prove a toolchain emits the sequence.
Fix
Add the 64-byte Cortex-M3 Thumb .text image, its complete MIT-licensed assembly source, and the Clang/LLD/LLVM objcopy 21.1.8 build recipe.
Testing
Exact-head readback confirms 64 bytes beginning f0b50028013000bf02bf401c15f4c03f and SHA-256 a49c1a151765f87446da09b98d6b11991f054a0a4ccb1d4ed2ea92694ad1f628. Two builds in separate fresh directories reproduced the source, object, ELF, and raw image byte-for-byte. Validation: #212 (comment)
THIS MESSAGE WAS GENERATED BY AN AUTOMATED PROCESS
Validation record for head 97ce07863c6d80a4145b73201dcb80d2da583332 against baseline 003e82a2bfa641530924055695b36cec8af483ab.
Exact PR shape: the own-merge-base/head scan verifies the added compiler-produced fixture and its load-bearing format/address shape: 64-byte raw Thumb fixture containing all four mixed-width IT lookback cases.
Provenance/reproduction: two fresh Clang 21.1.8 / LLD 21.1.8 / LLVM objcopy builds was rerun twice in separate fresh directories; both outputs byte-compare with each other and with the committed bytes.
Input/native identity: committed SHA-256 a49c1a151765f87446da09b98d6b11991f054a0a4ccb1d4ed2ea92694ad1f628; /proc/self/maps resolved pyvex/lib/libpyvex.so inside each isolated runtime on every arm: base SHA-256 4357c840876b955d15c2967a6bd8566bb03a19f07c1347cb3d157eed0f1156c6, head SHA-256 8950f2d7f75d84046913937d4f2458a269019b13ef6b8e55f643a42b083f574e.
Real consumer: Lifting: Handle mixed-width Thumb IT lookback pyvex#568 at baseline ab18a834ba4a5320c3415eff971092ef2b940779 / VEX 875f7c9a5f6be621b4f000c29c016e15ddf32207 and head 86716e788dc944bda3c0f7000096a15c1d7783ef / VEX 881703eda064a67a803cf51974c992286a8bdf4f loaded the committed fixture and produced the complete output linked in this PR's output record.
Repeat/order control: A/B/B/A, a static structural/native capture whose determinism is established by separate same-arm processes; same-arm output is byte-identical and the cross-arm delta is nonempty.
Local scope: this recapture validates fixture bytes, fixture shape, and the actual consumer path only. It does not claim a fresh full-workspace gate.
Hosted status: fresh hosted dependency validation for this exact binaries head has not been observed in this recapture; it remains pending and no hosted success is claimed here.
Rebased 2026-09-06; this record is re-keyed to the new head. The branch was replayed from 3de2c41a297606c45be7985aa09b3ae615424d61..84db56928c78a4bb72da3c16a180f03571421f9b onto binaries master 003e82a2bfa641530924055695b36cec8af483ab, giving 97ce07863c6d80a4145b73201dcb80d2da583332: git range-diff marks every commit =, the two git diff <merge-base>...<head> outputs hash to the same object, and every path the branch touches has the same blob at the old and the new head, so master left those paths alone. The figures above therefore describe the same bytes on a new base. It moved because a pull request that pins this one is checked out by CI at this branch's tip rather than merged with master, so the consumer was building against a binaries tree missing fixtures that were already on master. angr/binaries runs no pull-request workflow, so there is no run at the new head to cite — check-runs and actions/runs report 0 there, as they do for every pull request in this repository.
THIS MESSAGE WAS GENERATED BY AN AUTOMATED PROCESS
Exact fixture-shape and consumer-output record for #212.
Fixture comparison: own merge base a87538bc248531d2a1d22434143e8b9752459bac versus exact head b16b950949fb7981634b0ff76372422c21b36456. The target path/shape is absent on the merge base and present on the head. 64-byte raw Thumb fixture containing all four mixed-width IT lookback cases.
Fixture identity: SHA-256 a49c1a151765f87446da09b98d6b11991f054a0a4ccb1d4ed2ea92694ad1f628; source provenance: the adjacent complete assembly source at this exact binaries head. The complete readelf/objdump scan is retained with the exact script. The recorded recipe (two fresh Clang 21.1.8 / LLD 21.1.8 / LLVM objcopy builds) was rerun twice in fresh directories; both runs are byte-identical to the committed fixture.
Actual consumer: Lifting: Handle mixed-width Thumb IT lookback pyvex#568, exact baseline ab18a834ba4a5320c3415eff971092ef2b940779 / VEX 875f7c9a5f6be621b4f000c29c016e15ddf32207 versus exact head 86716e788dc944bda3c0f7000096a15c1d7783ef / VEX 881703eda064a67a803cf51974c992286a8bdf4f; target four exact IRSB lifts; configuration PyVEX opt-level 1 (plus recorded case controls).
Native identity: /proc/self/maps resolved pyvex/lib/libpyvex.so inside each isolated runtime on every arm: base SHA-256 4357c840876b955d15c2967a6bd8566bb03a19f07c1347cb3d157eed0f1156c6, head SHA-256 8950f2d7f75d84046913937d4f2458a269019b13ef6b8e55f643a42b083f574e.
Determinism: fresh A/B/B/A order, a static structural/native capture whose determinism is established by separate same-arm processes; each same-arm pair is byte-identical and every base/head comparison below is nonempty. Absolute checkout prefixes in tracebacks are normalized to <workspace> for publication; raw output is retained unchanged.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
THIS MESSAGE WAS GENERATED BY AN AUTOMATED PROCESS
Problem
PyVEX's Thumb regressions need a real instruction stream that combines a mixed 16/32/16-bit
ITTTgroup, a false0xbf08IT candidate insideLDREX, and the nine-halfword lookback edge. Binaries master has notests/armel/thumb_it_lookback_widths.bin.Root cause
The lookback decision depends on actual Thumb instruction widths and alignment. Synthetic bytes in the consumer test would bypass the workspace's real-fixture policy and would not prove a toolchain emits the sequence.
Fix
Add the 64-byte Cortex-M3 Thumb
.textimage, its complete MIT-licensed assembly source, and the Clang/LLD/LLVM objcopy 21.1.8 build recipe.Testing
Exact-head readback confirms 64 bytes beginning
f0b50028013000bf02bf401c15f4c03fand SHA-256a49c1a151765f87446da09b98d6b11991f054a0a4ccb1d4ed2ea92694ad1f628. Two builds in separate fresh directories reproduced the source, object, ELF, and raw image byte-for-byte. Validation: #212 (comment)session: sharpen