Re: port-amd64/54052: bump STACK_ALIGNBYTES for COMPAT_LINUX

[Kamil Rytarowski <n54%gmx.com@localhost>]

The following reply was made to PR port-amd64/54052; it has been noted by GNATS.

From: Kamil Rytarowski <n54%gmx.com@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: port-amd64/54052: bump STACK_ALIGNBYTES for COMPAT_LINUX
Date: Tue, 12 Mar 2019 10:53:30 +0100

 On 12.03.2019 10:00, Rin Okuyama wrote:
 > The following reply was made to PR port-amd64/54052; it has been noted by GNATS.
 > 
 > From: Rin Okuyama <rokuyama.rk%gmail.com@localhost>
 > To: Joerg Sonnenberger <joerg%bec.de@localhost>, gnats-bugs%NetBSD.org@localhost
 > Cc: port-amd64-maintainer%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
 >  netbsd-bugs%netbsd.org@localhost
 > Subject: Re: port-amd64/54052: bump STACK_ALIGNBYTES for COMPAT_LINUX
 > Date: Tue, 12 Mar 2019 17:55:47 +0900
 > 
 >  On 2019/03/12 7:54, Joerg Sonnenberger wrote:
 >  > On Mon, Mar 11, 2019 at 05:50:00AM +0000, rokuyama.rk%gmail.com@localhost wrote:
 >  >>> Description:
 >  >> Linux binaries with glibc >= 2.23 randomly crashes in dynamic linker.
 >  >> By bisectioning, the cause turns out to be this commit
 >  >>
 >  >> https://github.molgen.mpg.de/git-mirror/glibc/commit/38d22f9f48a84b441c5777aff103f5b980243b5f
 >  > 
 >  > So the real problem is that ld.so doesn't do what any normal startup
 >  > code does by aligning the stack explicitly. *sigh*
 >  
 >  I don't get what you means...
 >  
 >  (1) The bottom of stack (i.e., %rsp = &argc) is required to be aligned
 >  to 16-byte boundary by "System V ABI - AMD64 Architecture Processor
 >  Supplement"
 >  
 >  https://www.uclibc.org/docs/psABI-x86_64.pdf
 >  
 >  (see pp. 29-30).
 >  
 >  (2) However, we align it to only 8-byte boundary; we don't define
 >  STACK_ALIGNBYTES for amd64, and __ALIGNBYTES = (8 - 1) is used instead:
 >  
 >  src/sys/kern/kern_exec.c
 >  https://nxr.netbsd.org/xref/src/sys/kern/kern_exec.c#1394
 >  
 >     1394  static size_t
 >     1395  calcstack(struct execve_data * restrict data, const size_t gaplen)
 >     1396  {
 >     ....
 >     1415          /* make the stack "safely" aligned */
 >     1416          return STACK_LEN_ALIGN(stacklen, STACK_ALIGNBYTES);
 >     1417  }
 >  
 >  (3) If the bottom of stack is aligned to 16-byte boundary, ld.so for
 >  Linux works fine.
 >  
 >  Therefore, I think that ld.so is legal within System V ABI. Isn't it?
 >  
 >  Thanks,
 >  rin
 >  
 > 
 
 We have got a real-world use-case where we want to bypass libc/csu in
 LLDB and not rely on _start in assembly, because it does not scale to
 more than 1 CPU. We are generating core(5) files in LLDB test-suite and
 we could just write _start in C like in Linux:
 
 https://github.com/llvm-mirror/lldb/blob/master/packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/main.c
 
 Stack manual alignment is the only reason for us to write _start in .S
 rather than C code. We have decided to pick libc in our core(5) files in
 LLDB's test-suite but it has side effects (most importantly 20x larger
 core dumps)
 
 I'm for this change to get the stack alignment right by default.
 
 Linux emulation is now the 2nd use-case.