Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.arch
Subject: Re: Segments
Date: Thu, 23 Jan 2025 11:52:32 +0200
Organization: A noiseless patient Spider
Lines: 97
Message-ID: <20250123115232.0000242e@yahoo.com>
References: <bdZeP.23664$Hfb1.16566@fx46.iad>
	<vmavsb$3gpni$1@dont-email.me>
	<vmbd4n$3v6su$3@paganini.bofh.team>
	<vmbsvr$3lpar$1@dont-email.me>
	<vme199$4g29$1@dont-email.me>
	<b3h0pjhe3gpa84hev3ffbsmq9d3fmcfs49@4ax.com>
	<0a716d8979e4f539138c8068da250b3f@www.novabbs.org>
	<0I7kP.72725$oCrf.34275@fx33.iad>
	<7b08b7086bd94775b9d88b844763f122@www.novabbs.org>
	<y7ckP.76377$ZEZf.61315@fx40.iad>
	<b5002f983fc0ac6c112dca814b5e1cff@www.novabbs.org>
	<xxekP.41474$TgDc.28013@fx38.iad>
	<20250123013929.00004bc5@yahoo.com>
	<5xgkP.917152$DPl.624143@fx13.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 23 Jan 2025 10:52:47 +0100 (CET)
Injection-Info: dont-email.me; posting-host="c03a47e17d1f89f3d628205efa8f4fa3";
	logging-data="1657191"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX193/KE2wY21J7KfX85nZKjjwP2lFoTLz6E="
Cancel-Lock: sha1:tdAcU+iaEKO8WuQKIPYdDiTzuQ4=
X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32)
Bytes: 5589

On Thu, 23 Jan 2025 01:00:49 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:

> Michael S <already5chosen@yahoo.com> writes:
> >On Wed, 22 Jan 2025 22:44:45 GMT
> >scott@slp53.sl.home (Scott Lurndal) wrote:
> >  
> >> mitchalsup@aol.com (MitchAlsup1) writes:  
> >> >On Wed, 22 Jan 2025 20:00:30 +0000, Scott Lurndal wrote:
> >> >    
> >> >> mitchalsup@aol.com (MitchAlsup1) writes:    
> >> >>>On Wed, 22 Jan 2025 14:58:04 +0000, Scott Lurndal wrote:    
> >> >>>>(MitchAlsup1)    
> >> >>    
> >> >>>>>On a Linux machine, you can find the last envp[*] entry and
> >> >>>>>subtract SP from it.    
> >> >>>>
> >> >>>> I would discourage programmers from relying on that for any
> >> >>>> reason whatsoever.   The aux vectors are pushed before the
> >> >>>> envp entries.    
> >> >>>
> >> >>>This brings into question what is "on" the stack ?? to be
> >> >>>included in the measurement of stack size.
> >> >>>
> >> >>>Only user data ??
> >> >>>Data that is present when control arrives ??
> >> >>>Could <equivalent> CRT0 store SP at arrival ??
> >> >>>
> >> >>>I think we have an illdefined measurement !!    
> >> >>
> >> >> Everything between the base address of the stack
> >> >> and the limit address of the stack.  The kernel exec(2)
> >> >> family system calls will allocate the initial
> >> >> stack region (with guard pages to handle extension)
> >> >> and populate it with the AUX, ENVP and ARG vectors
> >> >> before invoking the CRT in usermode.    
> >> >
> >> >So, how does one find the base (highest address on the stack) ??
> >> >in a way that works on every system capable of running C-code ??
> >> >  
> >> 
> >> It's not something that a programmer generally would need, or want
> >> to do.  
> >> 
> >> However, if the OS they're using has a guard page to prevent
> >> stack underflow, one could write a subroutine which accesses
> >> page-aligned addresses towards the beginning of the stack
> >> region (anti the direction of growth) until a
> >> SIGSEGV is delivered.
> >>  
> >
> >Not every system capable of running C supports signals. I would
> >think that those that support signals are not even majority.  
> 
> Linux and MAC can't touch windows in terms of volume - but I'd
> argue that in the universe of programmers, they're close to
> if not equal to windows.  The vast vast majority of windows
> users don't have a compiler.  Those that do are working at
> a higher level where the knowlege of the stack base address
> would not be a useful value to know.
> 

I did not have "big" computers in mind. In fact, if we only look at
"big" things then Android dwarfs anything else. And while Android is not
POSIX complaint, it is probably similar enough for your method to work.

I had in mind smaller things.
All but one of very many embedded environments that I touched in
last 3 decades had no signals. The exceptional one was running
Linux.

> Unix (bsd/sysv) and linux support the ucontex argument
> on the signal handler which provides processor state so
> the signal handler can recover from the fault in whatever
> fashion makes sense then transfer control to a known
> starting point (either siglongjmp or by manipulating the
> return context provided to the signal handler). This is
> clearly going to be processor and implementation specific.
> 
> Yes, Windows is an abberation.   I offered a solution, not
> "the" solution. I haven't seen any valid reason for a program[*]
> to need to know the base address of the process stack; if there
> were a need, the implementation would provide.   I believe windows
> does have a functional equivalent to SIGSEGV, no?  A quick search
> shows "EXCEPTION_ACCESS_VIOLATION" for windows.
>

But then one would have to use SEH which is not the same as signals.
Although a specific case of SIGSEGV is the one where the SEH and
signals happen to be rather similar.
I can try it one day, but not today.

> [*] Leaving aside the rare system utility or diagnostic
>     utility or library (e.g. valgrind, et alia may find
>     that a useful datum).