Confusing x0 register operations under an Arm64EC target

[scout-zeng]

We are trying to integrate V8 as an Arm64EC dynamic library into x64 Node.js. When running Node.js on a Windows on ARM PC, we encountered a crash. Through WinDbg analysis, we found that in v8_libbase.dll(ARM64EC build), there is a piece of assembly code that manipulates the x0 register before calling the function v8_libbase!v8::base::Vector::length. As a result, the length value obtained is not the valid value we expect, which lead s to the program crashing. The code snippet is as follows:

00007fff`4c78aa10 d10183ff sub         sp,sp,#0x60
00007fff`4c78aa14 a9057bfd stp         fp,lr,[sp,#0x50]
00007fff`4c78aa18 910143fd add         fp,sp,#0x50
00007fff`4c78aa1c b0000228 adrp        x8,v8_libbase!v8::base::g_abort_mode (00007fff`4c7cf000)
00007fff`4c78aa20 f9418108 ldr         x8,[x8,#0x300]
00007fff`4c78aa24 f81f83a8 stur        x8,[fp,#-8]
00007fff`4c78aa28 f81f03a1 stur        x1,[fp,#-0x10]
00007fff`4c78aa2c f81e83a0 stur        x0,[fp,#-0x18]
00007fff`4c78aa30 f81e03a3 stur        x3,[fp,#-0x20]
00007fff`4c78aa34 f90017e2 str         x2,[sp,#0x28]
00007fff`4c78aa38 f85e03a8 ldur        x8,[fp,#-0x20]
00007fff`4c78aa3c f9000fe8 str         x8,[sp,#0x18]
00007fff`4c78aa40 f94017e8 ldr         x8,[sp,#0x28]
00007fff`4c78aa44 f9000be8 str         x8,[sp,#0x10]
00007fff`4c78aa48 d10063a0 sub         x0,fp,#0x18
00007fff`4c78aa4c f90003e0 str         x0,[sp]
00007fff`4c78aa50 94000018 bl          v8_libbase!v8::base::Vector<char>::length (00007fff`4c78aab0)
00007fff`4c78aa54 2a0003e1 mov         w1,w0
00007fff`4c78aa58 f94003e0 ldr         x0,[sp]
00007fff`4c78aa5c b9000fe1 str         w1,[sp,#0xC]
00007fff`4c78aa60 94000049 bl          v8_libbase!v8::base::Vector<char>::begin (00007fff`4c78ab84)
00007fff`4c78aa64 b9400fe1 ldr         w1,[sp,#0xC]
00007fff`4c78aa68 f9400be2 ldr         x2,[sp,#0x10]
00007fff`4c78aa6c f9400fe3 ldr         x3,[sp,#0x18]
00007fff`4c78aa70 94003e88 bl          v8_libbase!v8::base::OS::VSNPrintF (00007fff`4c79a490)
00007fff`4c78aa74 b90027e0 str         w0,[sp,#0x24]
00007fff`4c78aa78 f85f83a9 ldur        x9,[fp,#-8]
00007fff`4c78aa7c b0000228 adrp        x8,v8_libbase!v8::base::g_abort_mode (00007fff`4c7cf000)
00007fff`4c78aa80 f9418108 ldr         x8,[x8,#0x300]
00007fff`4c78aa84 eb090108 subs        x8,x8,x9
00007fff`4c78aa88 54000041 bne         v8_libbase!v8::base::VSNPrintF+0x80 (00007fff`4c78aa90)
00007fff`4c78aa8c 14000004 b           v8_libbase!v8::base::VSNPrintF+0x8c (00007fff`4c78aa9c)
00007fff`4c78aa90 f85f83a0 ldur        x0,[fp,#-8]
00007fff`4c78aa94 94005ba3 bl          v8_libbase!#__security_check_cookie_arm64ec (00007fff`4c7a1920)
00007fff`4c78aa98 d4200020 brk         #1
00007fff`4c78aa9c b94027e0 ldr         w0,[sp,#0x24]
00007fff`4c78aaa0 a9457bfd ldp         fp,lr,[sp,#0x50]
00007fff`4c78aaa4 910183ff add         sp,sp,#0x60
00007fff`4c78aaa8 d65f03c0 ret
00007fff`4c78aaac 0001ece9 ???

The llvm/clang version we use is 21.1.3

[llvmbot]

@llvm/issue-subscribers-backend-aarch64

Author: None (scout-zeng)

We are trying to integrate V8 as an Arm64EC dynamic library into x64 Node.js. When running Node.js on a Windows on ARM PC, we encountered a crash. Through WinDbg analysis, we found that in v8_libbase.dll(ARM64EC build), there is a piece of assembly code that manipulates the x0 register before calling the function v8_libbase!v8::base::Vector<char>::length. As a result, the length value obtained is not the valid value we expect, which lead s to the program crashing. The code snippet is as follows: ```asm 00007fff`4c78aa10 d10183ff sub sp,sp,#0x60 00007fff`4c78aa14 a9057bfd stp fp,lr,[sp,#0x50] 00007fff`4c78aa18 910143fd add fp,sp,#0x50 00007fff`4c78aa1c b0000228 adrp x8,v8_libbase!v8::base::g_abort_mode (00007fff`4c7cf000) 00007fff`4c78aa20 f9418108 ldr x8,[x8,#0x300] 00007fff`4c78aa24 f81f83a8 stur x8,[fp,#-8] 00007fff`4c78aa28 f81f03a1 stur x1,[fp,#-0x10] 00007fff`4c78aa2c f81e83a0 stur x0,[fp,#-0x18] 00007fff`4c78aa30 f81e03a3 stur x3,[fp,#-0x20] 00007fff`4c78aa34 f90017e2 str x2,[sp,#0x28] 00007fff`4c78aa38 f85e03a8 ldur x8,[fp,#-0x20] 00007fff`4c78aa3c f9000fe8 str x8,[sp,#0x18] 00007fff`4c78aa40 f94017e8 ldr x8,[sp,#0x28] 00007fff`4c78aa44 f9000be8 str x8,[sp,#0x10] 00007fff`4c78aa48 d10063a0 sub x0,fp,#0x18 00007fff`4c78aa4c f90003e0 str x0,[sp] 00007fff`4c78aa50 94000018 bl v8_libbase!v8::base::Vector<char>::length (00007fff`4c78aab0) 00007fff`4c78aa54 2a0003e1 mov w1,w0 00007fff`4c78aa58 f94003e0 ldr x0,[sp] 00007fff`4c78aa5c b9000fe1 str w1,[sp,#0xC] 00007fff`4c78aa60 94000049 bl v8_libbase!v8::base::Vector<char>::begin (00007fff`4c78ab84) 00007fff`4c78aa64 b9400fe1 ldr w1,[sp,#0xC] 00007fff`4c78aa68 f9400be ldr x2,[sp,#0x10] 00007fff`4c78aa6c f9400fe3 ldr x3,[sp,#0x18] 00007fff`4c78aa70 94003e88 bl v8_libbase!v8::base::OS::VSNPrintF (00007fff`4c79a490) 00007fff`4c78aa74 b90027e0 str w0,[sp,#0x24] 00007fff`4c78aa78 f85f83a9 ldur x9,[fp,#-8] 00007fff`4c78aa7c b0000228 adrp x8,v8_libbase!v8::base::g_abort_mode (00007fff`4c7cf000) 00007fff`4c78aa80 f9418108 ldr x8,[x8,#0x300] 00007fff`4c78aa84 eb090108 subs x8,x8,x9 00007fff`4c78aa88 54000041 bne v8_libbase!v8::base::VSNPrintF+0x80 (00007fff`4c78aa90) 00007fff`4c78aa8c 14000004 b v8_libbase!v8::base::VSNPrintF+0x8c (00007fff`4c78aa9c) 00007fff`4c78aa90 f85f83a0 ldur x0,[fp,#-8] 00007fff`4c78aa94 94005ba3 bl v8_libbase!#__security_check_cookie_arm64ec (00007fff`4c7a1920) 00007fff`4c78aa98 d4200020 brk #1 00007fff`4c78aa9c b94027e0 ldr w0,[sp,#0x24] 00007fff`4c78aaa0 a9457bfd ldp fp,lr,[sp,#0x50] 00007fff`4c78aaa4 910183ff add sp,sp,#0x60 00007fff`4c78aaa8 d65f03c0 ret 00007fff`4c78aaac 0001ece9 ???

The llvm/clang version we use is 21.1.3
</details>

[efriedma-quic]

sub x0,fp,#0x18 is loading the address of a stack variable into x0. I think that variable is supposed to be a Vector<char>... and it looks like there's code to initialize that variable. I don't see anything wrong with that, at first glance. And I don't see any arm64ec-specific constructs here, unless there's a variadic function somewhere.

[efriedma-quic]

Looking at the source code, VSNPrintF isn't variadic, and it isn't doing anything interesting itself. But it does have a va_list as an argument, so it's probably getting called by v8::base::SNPrintF. Maybe the issue is in the caller?

[scout-zeng]

stur        x0,[fp,#-0x18]

This assembly instruction stores the value of the x0 register into stack memory. x0 is a pointer to a Vector type. When calling v8_libbase!v8::base::Vector::length, I believe x0 itself should be passed, rather than the address in stack memory where x0 is stored at fp - 0x18 — that is, not a double pointer.
And the related CC code are as follows:
v8\src\base\strings.cc

namespace v8 {
namespace base {

int VSNPrintF(Vector<char> str, const char* format, va_list args) {
  return OS::VSNPrintF(str.begin(), str.length(), format, args);
}

int SNPrintF(Vector<char> str, const char* format, ...) {
  va_list args;
  va_start(args, format);
  int result = VSNPrintF(str, format, args);
  va_end(args);
  return result;
}

void StrNCpy(base::Vector<char> dest, const char* src, size_t n) {
  base::OS::StrNCpy(dest.begin(), dest.length(), src, n);
}

}  // namespace base
}  // namespace v8

v8\src\base\Vector.h

  // Returns the length of the vector. Only use this if you really need an
  // integer return value. Use {size()} otherwise.
  int length() const {
    CHECK_GE(std::numeric_limits<int>::max(), length_);
    return static_cast<int>(length_);
  }

The function call chain is as follows:
v8::base::SNPrintF -> v8::base::VSNPrintF -> v8::base::Vector::length()

[efriedma-quic]

I think you're misinterpreting the code. The beginning of the function reference four argument registers: x0, x1, x2, and x3. x0 and x1 contain the value of the Vector, x2 is the format string, and x3 is the va_list.

I'd believe you if you told me that SNPrintF is sticking a pointer to the Vector in x0, instead of the value, but that would be a bug in SNPrintF, not VSNPrintF. And you haven't shown the disassembly for that.

[scout-zeng]

The disassembly code for v8::base::SNPrintF are as follows. From the dt command, we can infer that x0 is passing a pointer.

0:000:ARM64EC> dt v8_libbase!v8::base::Vector<char> @x0
   +0x000 start_           : 0x000001fc`59fad758  ".???"
   +0x008 length_          : 0x32

v8_libbase!v8::base::SNPrintF:
00007fff`4c78aba0 d10183ff sub         sp,sp,#0x60
00007fff`4c78aba4 a9047bfd stp         fp,lr,[sp,#0x40]
00007fff`4c78aba8 910103fd add         fp,sp,#0x40
00007fff`4c78abac f81f8c83 str         x3,[x4,#-8]!
00007fff`4c78abb0 b0000228 adrp        x8,v8_libbase!v8::base::g_abort_mode (00007fff`4c7cf000)
00007fff`4c78abb4 f9418108 ldr         x8,[x8,#0x300]
00007fff`4c78abb8 f81f83a8 stur        x8,[fp,#-8]
00007fff`4c78abbc f81f03a1 stur        x1,[fp,#-0x10]
00007fff`4c78abc0 f81e83a0 stur        x0,[fp,#-0x18]
00007fff`4c78abc4 f90007e2 str         x2,[sp,#8]
00007fff`4c78abc8 f90013e4 str         x4,[sp,#0x20]
00007fff`4c78abcc f94013e3 ldr         x3,[sp,#0x20]
00007fff`4c78abd0 f94007e2 ldr         x2,[sp,#8]
00007fff`4c78abd4 3cde83a0 ldur        q0,[fp,#-0x18]
00007fff`4c78abd8 3d8007e0 str         q0,[sp,#0x10]
00007fff`4c78abdc f9400fe1 ldr         x1,[sp,#0x18]
00007fff`4c78abe0 f9400be0 ldr         x0,[sp,#0x10]
00007fff`4c78abe4 97ffff8b bl          v8_libbase!v8::base::VSNPrintF (00007fff`4c78aa10)
00007fff`4c78abe8 b90007e0 str         w0,[sp,#4]
00007fff`4c78abec b94007e8 ldr         w8,[sp,#4]
00007fff`4c78abf0 b90003e8 str         w8,[sp]
00007fff`4c78abf4 f85f83a9 ldur        x9,[fp,#-8]
00007fff`4c78abf8 b0000228 adrp        x8,v8_libbase!v8::base::g_abort_mode (00007fff`4c7cf000)
00007fff`4c78abfc f9418108 ldr         x8,[x8,#0x300]
00007fff`4c78ac00 eb090108 subs        x8,x8,x9
00007fff`4c78ac04 54000041 bne         v8_libbase!v8::base::SNPrintF+0x6c (00007fff`4c78ac0c)
00007fff`4c78ac08 14000004 b           v8_libbase!v8::base::SNPrintF+0x78 (00007fff`4c78ac18)
00007fff`4c78ac0c f85f83a0 ldur        x0,[fp,#-8]
00007fff`4c78ac10 94005b44 bl          v8_libbase!#__security_check_cookie_arm64ec (00007fff`4c7a1920)
00007fff`4c78ac14 d4200020 brk         #1
00007fff`4c78ac18 b94003e0 ldr         w0,[sp]
00007fff`4c78ac1c a9447bfd ldp         fp,lr,[sp,#0x40]
00007fff`4c78ac20 910183ff add         sp,sp,#0x60

[scout-zeng]

The disassembly code for v8::base::SNPrintF are as follows. From the dt command, we can infer that x0 is passing a pointer.

 0:000:ARM64EC> dt v8_libbase!v8::base::Vector<char> @x0
    +0x000 start_           : 0x000001fc`59fad758  ".???"
    +0x008 length_          : 0x32

> v8_libbase!v8::base::SNPrintF:
> 00007fff`4c78aba0 d10183ff sub         sp,sp,#0x60
> 00007fff`4c78aba4 a9047bfd stp         fp,lr,[sp,#0x40]
> 00007fff`4c78aba8 910103fd add         fp,sp,#0x40
> 00007fff`4c78abac f81f8c83 str         x3,[x4,#-8]!
> 00007fff`4c78abb0 b0000228 adrp        x8,v8_libbase!v8::base::g_abort_mode (00007fff`4c7cf000)
> 00007fff`4c78abb4 f9418108 ldr         x8,[x8,#0x300]
> 00007fff`4c78abb8 f81f83a8 stur        x8,[fp,#-8]
> 00007fff`4c78abbc f81f03a1 stur        x1,[fp,#-0x10]
> 00007fff`4c78abc0 f81e83a0 stur        x0,[fp,#-0x18]
> 00007fff`4c78abc4 f90007e2 str         x2,[sp,#8]
> 00007fff`4c78abc8 f90013e4 str         x4,[sp,#0x20]
> 00007fff`4c78abcc f94013e3 ldr         x3,[sp,#0x20]
> 00007fff`4c78abd0 f94007e2 ldr         x2,[sp,#8]
> 00007fff`4c78abd4 3cde83a0 ldur        q0,[fp,#-0x18]
> 00007fff`4c78abd8 3d8007e0 str         q0,[sp,#0x10]
> 00007fff`4c78abdc f9400fe1 ldr         x1,[sp,#0x18]
> 00007fff`4c78abe0 f9400be0 ldr         x0,[sp,#0x10]
> 00007fff`4c78abe4 97ffff8b bl          v8_libbase!v8::base::VSNPrintF (00007fff`4c78aa10)
> 00007fff`4c78abe8 b90007e0 str         w0,[sp,#4]
> 00007fff`4c78abec b94007e8 ldr         w8,[sp,#4]
> 00007fff`4c78abf0 b90003e8 str         w8,[sp]
> 00007fff`4c78abf4 f85f83a9 ldur        x9,[fp,#-8]
> 00007fff`4c78abf8 b0000228 adrp        x8,v8_libbase!v8::base::g_abort_mode (00007fff`4c7cf000)
> 00007fff`4c78abfc f9418108 ldr         x8,[x8,#0x300]
> 00007fff`4c78ac00 eb090108 subs        x8,x8,x9
> 00007fff`4c78ac04 54000041 bne         v8_libbase!v8::base::SNPrintF+0x6c (00007fff`4c78ac0c)
> 00007fff`4c78ac08 14000004 b           v8_libbase!v8::base::SNPrintF+0x78 (00007fff`4c78ac18)
> 00007fff`4c78ac0c f85f83a0 ldur        x0,[fp,#-8]
> 00007fff`4c78ac10 94005b44 bl          v8_libbase!#__security_check_cookie_arm64ec (00007fff`4c7a1920)
> 00007fff`4c78ac14 d4200020 brk         #1
> 00007fff`4c78ac18 b94003e0 ldr         w0,[sp]
> 00007fff`4c78ac1c a9447bfd ldp         fp,lr,[sp,#0x40]
> 00007fff`4c78ac20 910183ff add         sp,sp,#0x60

The crash was caused by the v8::base::length() method detecting that the length value exceeded int::max().
And the disassembly of v8::base::Vector::length are as follows:

00007fff`4c78aab0 d10183ff sub         sp,sp,#0x60
00007fff`4c78aab4 a9057bfd stp         fp,lr,[sp,#0x50]
00007fff`4c78aab8 910143fd add         fp,sp,#0x50
00007fff`4c78aabc f90017e0 str         x0,[sp,#0x28]
00007fff`4c78aac0 f94017e8 ldr         x8,[sp,#0x28]
00007fff`4c78aac4 f9000fe8 str         x8,[sp,#0x18]
00007fff`4c78aac8 14000001 b           v8_libbase!v8::base::Vector<char>::length+0x1c (00007fff`4c78aacc)
00007fff`4c78aacc f9400fe8 ldr         x8,[sp,#0x18]
00007fff`4c78aad0 f9400508 ldr         x8,[x8,#8]
00007fff`4c78aad4 f90007e8 str         x8,[sp,#8]
00007fff`4c78aad8 97ffbc14 bl          v8_libbase!std::numeric_limits<int>::max (00007fff`4c779b28)
00007fff`4c78aadc f94007e8 ldr         x8,[sp,#8]
00007fff`4c78aae0 f81e83a8 stur        x8,[fp,#-0x18]
00007fff`4c78aae4 b81e43a0 stur        w0,[fp,#-0x1C]
00007fff`4c78aae8 f85e83a9 ldur        x9,[fp,#-0x18]
00007fff`4c78aaec b85e43a8 ldur        w8,[fp,#-0x1C]
00007fff`4c78aaf0 f81f83a9 stur        x9,[fp,#-8]
00007fff`4c78aaf4 b81f43a8 stur        w8,[fp,#-0xC]
00007fff`4c78aaf8 b85f43a8 ldur        w8,[fp,#-0xC]
00007fff`4c78aafc 52800029 mov         w9,#1
00007fff`4c78ab00 b90017e9 str         w9,[sp,#0x14]
00007fff`4c78ab04 37f80108 tbnz        x8,#0x1F,v8_libbase!v8::base::Vector<char>::length+0x74 (00007fff`4c78ab24)
00007fff`4c78ab08 14000001 b           v8_libbase!v8::base::Vector<char>::length+0x5c (00007fff`4c78ab0c)
00007fff`4c78ab0c b85f43a8 ldur        w8,[fp,#-0xC]
00007fff`4c78ab10 f85f83a9 ldur        x9,[fp,#-8]
00007fff`4c78ab14 eb090108 subs        x8,x8,x9
00007fff`4c78ab18 1a9f27e8 csetlo      w8
00007fff`4c78ab1c b90017e8 str         w8,[sp,#0x14]
00007fff`4c78ab20 14000001 b           v8_libbase!v8::base::Vector<char>::length+0x74 (00007fff`4c78ab24)
00007fff`4c78ab24 b94017e9 ldr         w9,[sp,#0x14]
00007fff`4c78ab28 52800028 mov         w8,#1
00007fff`4c78ab2c 0a290108 bic         w8,w8,w9
00007fff`4c78ab30 39009fe8 strb        w8,[sp,#0x27]
00007fff`4c78ab34 14000001 b           v8_libbase!v8::base::Vector<char>::length+0x88 (00007fff`4c78ab38)
00007fff`4c78ab38 39409fe8 ldrb        w8,[sp,#0x27]
00007fff`4c78ab3c 37000148 tbnz        x8,#0,v8_libbase!v8::base::Vector<char>::length+0xb4 (00007fff`4c78ab64)
00007fff`4c78ab40 14000001 b           v8_libbase!v8::base::Vector<char>::length+0x94 (00007fff`4c78ab44)
00007fff`4c78ab44 90000140 adrp        x0,v8_libbase!`string' (00007fff`4c7b2000)
00007fff`4c78ab48 91040000 add         x0,x0,#0x100
00007fff`4c78ab4c b0000141 adrp        x1,v8_libbase!two_over_pi+0xc0 (00007fff`4c7b3000)
00007fff`4c78ab50 9118a021 add         x1,x1,#0x628
00007fff`4c78ab54 910003e4 mov         x4,sp
00007fff`4c78ab58 aa1f03e5 mov         x5,xzr
00007fff`4c78ab5c 97ffa6e1 bl          v8_libbase!V8_Fatal (00007fff`4c7746e0)
00007fff`4c78ab60 d4200020 brk         #1
00007fff`4c78ab64 14000001 b           v8_libbase!v8::base::Vector<char>::length+0xb8 (00007fff`4c78ab68)
00007fff`4c78ab68 14000001 b           v8_libbase!v8::base::Vector<char>::length+0xbc (00007fff`4c78ab6c)
00007fff`4c78ab6c f9400fe8 ldr         x8,[sp,#0x18]
00007fff`4c78ab70 b9400900 ldr         w0,[x8,#8]
00007fff`4c78ab74 a9457bfd ldp         fp,lr,[sp,#0x50]
00007fff`4c78ab78 910183ff add         sp,sp,#0x60
00007fff`4c78ab7c d65f03c0 ret
00007fff`4c78ab80 0001ec15 ???

Btw, the definition of v8::base::Vector

template <typename T>
class Vector {
private:
    T* start_;
    size_t length_;
}

[efriedma-quic]

Oh, I see what's happening, I think; there's an ABI disagreement about the signature of SNPrintF. This will be fixed by #152411.

[scout-zeng]

May I ask when this fix is expected to be merged into the main branch? It appears that this pull request still contains unresolved merge conflicts.

[efriedma-quic]

If it's important for you, I'll try to merge it within the next couple days.

[scout-zeng]

This is really important to me—my current work is blocked by this issue. It would be best if you could merge it as soon as possible.

[efriedma-quic]

#152411 is merged; let me know if that helps here.