Re: Segments

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