Bug 1891509
| Summary: | stap's debuginfod lookup fails in some cases on aarch64 and s390x (none ELF images) | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Martin Cermak <mcermak> |
| Component: | systemtap | Assignee: | Frank Ch. Eigler <fche> |
| systemtap sub component: | system-version | QA Contact: | qe-baseos-tools-bugs |
| Status: | CLOSED CANTFIX | Docs Contact: | |
| Severity: | medium | ||
| Priority: | medium | CC: | fche, lberk, mcermak, mjw |
| Version: | 8.4 | Keywords: | FutureFeature, Triaged |
| Target Milestone: | rc | ||
| Target Release: | 8.0 | ||
| Hardware: | Unspecified | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2022-03-28 10:49:18 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Martin Cermak
2020-10-26 13:50:47 UTC
I assume that on both arches the same versions of systemtap and elfutils are used? Could you provide the rpm nvrs of each package? Asking because there have been no updates for 8.4 yet. So I assume the same behavior can be seen on 8.3? Martin, see comment #1. Answers would help me setup a replicator. Reproduced again with elfutils-0.182-2.el8 and systemtap-4.3-4.el8. I've only indexed the kernel-`uname -r` by going to /mnt/redhat/brewroot/packages/kernel/4.18.0/240.10.el8/`arch` and from there running `debuginfod -R -vvv .`. Then `export DEBUGINFOD_URLS=http://localhost:8002/`, `export DEBUGINFOD_PROGRESS=1` and finally: rm -rf ~/.cache/debuginfod_client; stap -ve 'probe kernel.function("vfs_read"){ log("hey!"); exit() }' This works as expected on ppc64le and x86_64 (stap shows Downloading \ ... and finally succeedes to run the script). But on aarch64 and s390x, stap doesn't show the expected 'Downloading \', and eventually fails running the script because of "semantic error: resolution failed in DWARF builder", just as originally reported. The issue is the vmlinuz format. It is simplest to check with eu-readelf -h: eu-readelf -h /boot/vmlinuz-4.18.0-240.10.el8.x86_64 ELF Header: Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, little endian Ident Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: EXEC (Executable file) Machine: AMD x86-64 Version: 1 (current) Entry point address: 0x1000000 Start of program headers: 64 (bytes into file) Start of section headers: 56623512 (bytes into file) Flags: Size of this header: 64 (bytes) Size of program header entries: 56 (bytes) Number of program headers entries: 5 Size of section header entries: 64 (bytes) Number of section headers entries: 37 Section header string table index: 36 eu-readelf -h /boot/vmlinuz-4.18.0-240.10.el8.s390x eu-readelf: failed reading '/boot/vmlinuz-4.18.0-240.10.el8.s390x': not a valid ELF file eu-readelf -h /boot/vmlinuz-4.18.0-240.10.el8.ppc64le ELF Header: Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, little endian Ident Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: EXEC (Executable file) Machine: PowerPC64 Version: 1 (current) Entry point address: 0xc000000000000000 Start of program headers: 64 (bytes into file) Start of section headers: 28741512 (bytes into file) Flags: 0x2 Size of this header: 64 (bytes) Size of program header entries: 56 (bytes) Number of program headers entries: 3 Size of section header entries: 64 (bytes) Number of section headers entries: 50 Section header string table index: 49 eu-readelf -h /boot/vmlinuz-4.18.0-240.10.el8.aarch64 eu-readelf: failed reading '/boot/vmlinuz-4.18.0-240.10.el8.aarch64': not a valid ELF file *** Bug 1963037 has been marked as a duplicate of this bug. *** *** Bug 1962735 has been marked as a duplicate of this bug. *** *** Bug 1963042 has been marked as a duplicate of this bug. *** upstream systemtap commit 294b7a53ec2f forces #stap-prep to fail on these platforms, so as to avoid giving users a false confidence No progress on this on the elfutils side. But see comment #10 for a systemtap "workaround". Unclear what a good solution would be given that these images aren't ELF. I think this cannot be fixed on the elfutils side since we don't have an ELF image for these architectures. Maybe the systemtap workaround mentioned in comment #10 is enough? |