Re: pkg/57708: rust problem when building firefox

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

    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