Repository navigation
s390x: illegal instruction in unit tests #47064
Description
Activity
In mostly default compilation case, looking at the disassembly of the core file, it points to this instruction.
0x000002aa4023b0a2 <+834>: jg 0x2aa4023b0c0 <Builtins_MulHandler+864> 0x000002aa4023b0a8 <+840>: lg %r5,15(%r2) 0x000002aa4023b0ae <+846>: tmll %r4,1 0x000002aa4023b0b2 <+850>: jge 0x2aa4023b0c0 <Builtins_MulHandler+864> 0x000002aa4023b0b8 <+856>: lcgr %r4,%r5 0x000002aa4023b0bc <+860>: lgr %r5,%r4 0x000002aa4023b0c0 <+864>: mgrk %r0,%r8,%r5 => 0x000002aa4023b0c4 <+868>: lgr %r4,%r1 0x000002aa4023b0c8 <+872>: srag %r1,%r1,63 0x000002aa4023b0ce <+878>: clgr %r0,%r1 0x000002aa4023b0d2 <+882>: jgne 0x2aa4023b488 <Builtins_MulHandler+1832> 0x000002aa4023b0d8 <+888>: ltgr %r0,%r4 0x000002aa4023b0dc <+892>: jge 0x2aa4023b15c <Builtins_MulHandler+1020> 0x000002aa4023b0e2 <+898>: lay %r5,52552(%r10) 0x000002aa4023b0e8 <+904>: lg %r2,0(%r5) r0 0x2 2 r1 0x22 34 r2 0x456a9e8e31 298141519409 r3 0x85994415b1 573802026417 r4 0x2 2 r5 0x3b9aca00 1000000000 r6 0x39 57 r7 0x1 1 r8 0x640f08df 1678706911 r9 0x0 0 r10 0x2aa1a1e5070 2929605890160 r11 0x3ffd0cfce70 4397254823536 r12 0xc0 192 r13 0x85994415b1 573802026417 r14 0x2aa17b871e6 2929565659622 r15 0x3ffd0cfce28 4397254823464cc @nodejs/platform-s390
Thank you for reporting the issue, it's related to
MacroAssembler::MulHighS64usingmgrkwhich doesn't exist on z13, will need to check if there is a workaround.Looks like this was introduced in V8 by https://chromium-review.googlesource.com/c/v8/v8/+/3930898
@AdamMajer Hello, would you please verify if this v8 patch work for you? https://chromium-review.googlesource.com/c/v8/v8/+/4334353
@AdamMajer Hello, would you please verify if this v8 patch work for you? https://chromium-review.googlesource.com/c/v8/v8/+/4334353
Sorry for lateness of the reply. Checking now.
It looks like it still crashes in same unit tests. I will check which code path it's using there.
Finally, I'm looking at this again. Building now with 20.1.0 where the v8 patch is now included,
0x00000000026a74d6 <+822>: jge 0x26a74e4 <Builtins_MulHandler+836> 0x00000000026a74dc <+828>: lcgr %r4,%r5 0x00000000026a74e0 <+832>: lgr %r5,%r4 0x00000000026a74e4 <+836>: mgrk %r0,%r8,%r5 => 0x00000000026a74e8 <+840>: lgr %r4,%r1 0x00000000026a74ec <+844>: srag %r1,%r1,63 0x00000000026a74f2 <+850>: clgr %r0,%r1This looks like it's coming from
src/compiler/backend/s390/code-generator-s390.cc:1706
Hi Adam,
This CL is still WIP but once landed should solve this on z13: https://chromium-review.googlesource.com/c/v8/v8/+/4521297This CL is still WIP but once landed should solve this on z13: https://chromium-review.googlesource.com/c/v8/v8/+/4521297
Looks like this fixes the issue. I'll get back tomorrow if something pops up when all the tests run. Thanks!
Glad to hear, thanks for confirming.
All tests now pass on z13 and also z15. Thank you for fixing this!
Not a problem, thanks again for confirming.
- added a commit that references this issue
on Aug 31, 2023 - added a commit that references this issue
on Sep 10, 2023
Version
19.6.0
Platform
No response
Subsystem
v8
What steps will reproduce the bug?
No response
How often does it reproduce? Is there a required condition?
Every time
What is the expected behavior?
No errors
What do you see instead?
Compiling with mostly default options results in some unit tests failures in file system tests. All these ended up with <Builtins_MulHandler+868> on z13 while running just fine on z15 machine.
For example, when executing
test/parallel/test-fs-cp.mjsortest/parallel/test-fs-stat-bigint.jsI've then added
--v8-enable-object-print --v8-non-optimized-debug --v8-with-dchecksto the configure and rebuilt. During the build, the following error popped upwhich points to,
@export
macro IsHeapNumber(o: HeapObject): bool {
return Is(o);
}
And additionally adding
--v8-enable-short-builtin-callsto the configure, I get an error in the macro assembler for s390 where unreachable code is apparently reached.Additional information
Looking at the logs, the failures in the unit tests started with 19.3.0 and 19.1.0 was last version where everything worked. This seems to point to v8 update then as possible culprit.
#45230