testsuite: armv7l test failure #442
Comments
|
I don't know the cause of the failure, but armv7l is a 32-bit ARM processor, and mold isn't tested well on 32-bit hosts. I'll take a look when I have time. |
|
I think I might be experiencing same issue, it happens always on Lines 43 to 44 in b26e1a3 |
|
I've just tried the current master (5688115) and still see one failing test-case: |
|
I cannot reproduce it even with |
|
I'm attaching build log from openSUSE OBS: |
|
Thanks. It looks like the following test is also failing: I still cannot reproduce on my emulated ARM32 machine running Ubuntu 22.04. Can you share your build directory to me? |
|
@marxin what is |
|
Well, it's using KVM inside an aarch64 machine, but it should be fine, we use the setup of the entire openSUSE distribution. |
|
My point is test framework seems to assume Lines 39 to 42 in 7f7d10c That's why I pass |
|
Ah, I see. Well, it's fine in my case: |
|
Does this patch change make any difference? |
|
It's the same (for being sure attaching the build log): arm.txt |
|
I don't know how to debug this further without setting up the same environment as yours, so let me do that. That's OpenSUSE/ARMv7 right? |
|
Yes, it's |
|
Is there any progress on this, please? |
|
No progress, sorry. I'm not familiar with ARM64 and moreover ARM32 on ARM64, so I haven't figure out how to set up a test environment. |
I can reproduce this crash on a Raspberry Pi 2 running (or rather crawling 🐌) Fedora 36. It's sufficient to take a trivial test program and link it with mold: $ echo 'int main(void) { return 0; }' | cc -xc - -o exe -static -fuse-ld=mold
$ ./exe
Illegal instruction (core dumped)The stack trace reveals that the crash happens within the libc startup code: AnalysisNote that I am by no means an expert on the ARM processor architecture, so my findings are somewhat based on conjecture.
Compare this to the equivalent binary produced by the GNU BFD linker: The So it seems very likely that mold does not apply the relocation for this call correctly. In ... and an |
|
When dealing with Line 201 in a8d1e29 ... while lld does this: https://github.com/llvm/llvm-project/blob/164266739298b39d3eac8d79ad12d1d654e2825e/lld/ELF/Arch/ARM.cpp#L527 |
|
Possibly related: #468 |
|
@sicherha Thank you for your investigation! I think I can fix this issue now with it. |
|
Great, I can confirm that all tests except one work on |
|
It is odd that the test should have already been skipped if ASAN is enabled. We checked if |
|
The ASAN check doesn't apply here because the messages come from Valgrind, which is called in line 90 of the script. |
|
Yeah but we have this at line 19, so the entire script should have been skipped.
|
|
I believe in this instance However, I cannot reproduce @marxin's finding with mold 1.4.0 and Fedora 36 on a Raspberry Pi 2: in my case, Valgrind does not report any errors. This is with Valgrind 3.19.0 and glibc 2.35. |
|
@sicherha Ah, you are right. I missed that point. It doesn't seems that the additional valgrind test add much value, and this is the only place we use valgrind. I think we can just remove these lines altogether. |
|
Agreed. |
I noticed the following test failure on the target:
arm-build.log.txt
The text was updated successfully, but these errors were encountered: