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 17:41:16 +0200
Organization: A noiseless patient Spider
Lines: 132
Message-ID: <20250123174116.00003bc2@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>
	<20250123115232.0000242e@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 23 Jan 2025 16:41:31 +0100 (CET)
Injection-Info: dont-email.me; posting-host="c03a47e17d1f89f3d628205efa8f4fa3";
	logging-data="1718716"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18ZhKhgjrTY+JrU+AVs9lr8iHaLUGxT+9g="
Cancel-Lock: sha1:pBiZ3FLlD1ICLTHDlGYNeI49s24=
X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32)
Bytes: 6636

On Thu, 23 Jan 2025 11:52:32 +0200
Michael S <already5chosen@yahoo.com> wrote:

> 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).  
> 
> 

At the end, I can not resist myself and did it today, wasting an hour
and a half during which I was supposed to do real work.
With Microsoft's language extensions it was trivial.
But I don't know how to do it (on Windows) with gcc.

Code:

static void test(char** res, int depth) {
  *res = (char*)&res;
  if (depth > 0)
    test(res, depth-1);
}

int main()
{
  char* res=(char*)&res;
  __try { test(&res, 1000000); }
  __except(1) { // 1==EXCEPTION_EXECUTE_HANDLER
    printf("SEH __except block\n");
  }
  printf("%p - %p = %zd\n", &res, res, (char*)&res - res);
  return 0;
}


It prints:
SEH __except block
000000000029F990 - 00000000001A4020 = 1030512