Re: pkg/57708: rust problem when building firefox

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR pkg/57708; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: Taylor R Campbell <riastradh%NetBSD.org@localhost>
Cc: he%NetBSD.org@localhost, gnats-bugs%NetBSD.org@localhost, netbsd-bugs%NetBSD.org@localhost
Subject: Re: pkg/57708: rust problem when building firefox
Date: Mon, 20 Nov 2023 13:12:48 +0700

     Date:        Sun, 19 Nov 2023 20:52:17 +0000
     From:        Taylor R Campbell <riastradh%NetBSD.org@localhost>
     Message-ID:  <20231119205217.CE5EE6083E%jupiter.mumble.net@localhost>
 
   | Which raises the question -- what is Rust trying to do with this
   | information and why?
 
 Purely from my reading of (not all of) the messages on this thread,
 my guess, and it is certainly no more than that, is that rust wants
 a guaranteed "dead" spot between the stack and other data ranges,
 guaranteed to cause an address fault if it is referenced (so there
 is no likely possibility that a process overflowing its stack might just
 hit some mapped data page and succeed) - and is willing to mmap() and
 mprotect() a region of memory itself to make that happen (if needed),
 but for that, needs to know where to put that in the address space.
 
 And second, when an address fault happens (SIGSEGV or whatever) it
 wants to be able to tell whether the fault happened in this dead space,
 and so was probably caused by a stack overflow (this might be just so
 it can print a different error message than it would for other address
 faults, before terminating the program).
 
 The other BSD implementations seem to know that a guard space is already
 placed at the bottom of the (max possible) stack growth area, so rust
 doesn't need to do anything to make one appear, and simply return the
 addresses that occupies (so rust can check if a faulting addr is in that
 space, I assume).
 
 There's just no NetBSD equiv code to the FreeBSD & OpenBSD versions (which
 differ).
 
 To me, for someone who knows how NetBSD address mapping for the stack is
 done, and how to access that from user space (via getrlimit() or sysctl()
 somehow) this should be simple ... and I think that one can assume that if
 rust provides a mechanism to allow a process to alter its max stack size,
 it will take care of learning about (or installing) a new guard region
 after that happens.
 
 kre