[BPF] fix print_btf.py test script on bigendian machines #110332
Merged
Conversation
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
|
@uweigand, could you please take a look? As far as I understand this has to land asap and I know that Yonghong is PTO today, and I need someone to review the change. |
|
(for the record, the change was tested locally on a big-endian virtual machine, as described here) |
uweigand
approved these changes
Sep 27, 2024
Thank you, will land once CI passes. |
|
Thanks @eddyz87 fixing the issue. I don't think the test failure is due to this patch. Maybe rebase on top of main branch and try again. |
eddyz87
force-pushed
the
print-btf-bigendian-fix
branch
from
7754810 to
b530cd5
Compare
Rebased and pushed, let's see what happens. |
eddyz87
force-pushed
the
print-btf-bigendian-fix
branch
from
b530cd5 to
f8da838
Compare
Make print_btf.py correctly detect endianness of the BTF input. Input endianness is inferred from BTF magic word [2], which is a 2-byte integer at offset 0 of the input: - sequence `EB 9F` signals big-endian input; - sequence `9F EB` signals little-endian input. Before this commit the magic sequence was read using "H" format for `unpack` method of python's `struct` module: - if magic is `0xEB9F` assume little-endian; - if magic is `0x9FEB` assume big-endian. However, format `H` reads data in native endianness. Thus the above logic would only be correct on little endian hosts: - byte sequence `9F EB` read as `0xEB9F` -> little-endian input; - byte sequence `EB 9F` read as `0x9FEB` -> big-endian input. On the big-endian host the relation should be inverse. Fix this by always reading magic in big-endian (format `>H`). This fixes CI error reported for a BPF test using print_btf.py script in [1]. The error happens on a s390 host, which is big-endian. [1] https://lab.llvm.org/buildbot/#/builders/42/builds/1192 [2] https://www.kernel.org/doc/html/latest/bpf/btf.html#btf-type-and-string-encoding
eddyz87
force-pushed
the
print-btf-bigendian-fix
branch
from
f8da838 to
522b861
Compare
|
The SystemZ build bots are all green again now, thanks! |
ingomueller-net
added a commit
to ingomueller-net/llvm-project
that referenced
this pull request
Oct 14, 2024
This PR revisits the traits and interfaces of the `alternatives`, `foreach`, and `yield`ops. First, it adds the `ReturnLike` trait to `transform.yield`. This is required in the one-shot bufferization pass since the merging of llvm#110332, which analyses any `FunctionOpInterface` and expects them to have a `ReturnLike` terminator. This uncovered problems with `alternatives` and `foreach`, which implemented the `BranchRegionOpInterface`. That interface verifies that the operands and results passed across the control flow edges from the parent op to its regions and back are equal (or compatible). Which results are passed back from regions to the parent op depend on the terminator and/or whether it is `ReturnLike`. Making `yield` a `ReturnLike` op, those checks fail without other changes. We explored and rejected the possibility to fix the implementation of `RegionBranchOpInterface` of the two concerned ops in llvm#111408. The problem is that the interface expects the result passed from a region to the parent op to *be* the result of the op, whereas in the two ops they *contribute* to the result: in `alternatives` only the operand yielded from one of the regions becomes the result whereas the others are ignored, and in `foreach` the operands from all iterations are fused into a new value that becomes the result of the op. Signed-off-by: Ingo Müller <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Make print_btf.py correctly detect endianness of the BTF input. Input endianness is inferred from BTF magic word [2], which is a 2-byte integer at offset 0 of the input:
EB 9Fsignals big-endian input;9F EBsignals little-endian input.Before this commit the magic sequence was read using "H" format for
unpackmethod of python'sstructmodule:0xEB9Fassume little-endian;0x9FEBassume big-endian.However, format
Hreads data in native endianness.Thus the above logic would only be correct on little endian hosts:
9F EBread as0xEB9F-> little-endian input;EB 9Fread as0x9FEB-> big-endian input.On the big-endian host the relation should be inverse.
Fix this by always reading magic in big-endian (format
>H).This fixes CI error reported for a BPF test using print_btf.py script in [1]. The error happens on a s390 host, which is big-endian.
[1] https://lab.llvm.org/buildbot/#/builders/42/builds/1192
[2] https://www.kernel.org/doc/html/latest/bpf/btf.html#btf-type-and-string-encoding