linux x64 release binary fails to exec on WSL1

[deepak1556]

Version

v24.16.0 (also reproduces on every v23.x and v24.x release; does not reproduce on v22.x)

Platform

Any **WSL1** distro. WSL2 is unaffected.

Subsystem

No response

What steps will reproduce the bug?

curl -LO https://nodejs.org/dist/v24.16.0/node-v24.16.0-linux-x64.tar.gz
tar xf node-v24.16.0-linux-x64.tar.gz
./node-v24.16.0-linux-x64/bin/node --version

How often does it reproduce? Is there a required condition?

Always, needs WSL1 distro

What is the expected behavior? Why is that the expected behavior?

node should exec and run normally on WSL1, as it did on v22.x. The 2MB p_align carries no runtime benefit for the Node executable today:

• Current executable is of type ET_EXEC with fixed p_vaddr. The kernel maps each PT_LOAD at its hard-coded address.
• The --use-largepages feature performs its hugepage remap at runtime; it never reads p_align.

So the lpstub PT_LOAD advertising p_align = 0x200000 is unnecessary, and clamping it to the page size (0x1000) is behavior-neutral for the runtime while restoring WSL1 compatibility.

What do you see instead?

cannot execute binary file: Exec format error

Additional information

The linux x64 binary ships a PT_LOAD segment (containing the lpstub section used by the --use-largepages feature) whose p_align is 2 MB:

# readelf -lW node-v24.16.0   (offending segment)
  Type  Offset    VirtAddr            ... Flg Align
  LOAD  0x2c00000 0x0000000003000000  ... R E 0x200000   <-- p_align = 2 MiB

#16198 introduced the section alignment (sh_addralign) for the code mover and its been there for a while. The regression started recently where the program headers started respecting it due to toolchain bump,

Node	Official linux-x64 toolchain	GNU ld	lpstub segment p_align
v22.x	RHEL 8 with gcc-toolset-10	binutils 2.35	0x1000 (works on WSL1)
v23.x	RHEL 8 with gcc-toolset-12	binutils 2.38	0x200000 (rejected)
v24.x	RHEL 8 with gcc-toolset-12	binutils 2.38	0x200000 (rejected)

binutils commit 74e315dbfe5, first released in binutils 2.38 added a code path in assign_file_positions_for_load_sections that, for a section whose alignment
exceeds maxpagesize (on x86-64 maxpagesize is 0x1000), stamps the segment's p_align to the section alignment. Under binutils 2.35 the segment's p_align was unconditionally maxpagesize (0x1000).

Kernel 5.10+ ce81bb256a22 respects the large p_align segment values for PIE binaries but it doesn't do any rejection in other cases. However, WSL1's binfmt_elf seems to reject any PT_LOAD whose p_align exceeds the system page size.

WSL is not a Tier 1 platform, thought I would raise this here for awareness and if there was interest to have a link time fix after seeing microsoft/WSL#8151. For VSCode remote server where I encountered this, applied a similar solution https://github.com/microsoft/vscode/pull/319355/changes

[joyeecheung]

cc @nodejs/build

[richardlau]

node/BUILDING.md

Lines 140 to 146 in 7b1b943

	[^3]: The Windows Subsystem for Linux (WSL) is not
	supported, but the GNU/Linux build process and binaries should work. The
	community will only address issues that reproduce on native GNU/Linux
	systems. Issues that only reproduce on WSL should be reported in the
	[WSL issue tracker](https://github.com/Microsoft/WSL/issues). Running the
	Windows binary (`node.exe`) in WSL will not work without workarounds such as
	stdio redirection.

Does it still occur on Node.js 26 where we've switched the toolchain to clang/llvm?

[deepak1556]

It does repro with v26.3.0, IIUC the linker has not been switched with the clang toolchain, its still gnu ld right ? Even with lld this will repro https://godbolt.org/z/oqvaK4bGj , the linkers are doing the right thing. The question is more about does Node.js want to keep the unused p_align that breaks WSL1 support or override it ?