Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #58631 > unrolled thread

local arrays and stack

Back to article view | Back to comp.lang.c

Contents

  local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-22 01:51 -0700
    local arrays and stack asetofsymbols@gmail.com - 2015-03-22 02:23 -0700
    Re: local arrays and stack Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-22 13:22 -0700
      Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-23 01:55 -0700
    Re: local arrays and stack Xcott Craver <xcottcraver@gmail.com> - 2015-03-22 15:07 -0700
      Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-23 01:50 -0700
        Re: local arrays and stack Robert Wessel <robertwessel2@yahoo.com> - 2015-03-23 04:26 -0500
          Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-23 06:53 -0700
          Re: local arrays and stack Xcott Craver <xcottcraver@gmail.com> - 2015-03-23 07:29 -0700
            Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-23 08:34 -0700
            Re: local arrays and stack Robert Wessel <robertwessel2@yahoo.com> - 2015-03-23 19:57 -0500
            Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-24 04:01 -0700
              Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-24 04:37 -0700
              Re: local arrays and stack David Brown <david.brown@hesbynett.no> - 2015-03-24 13:04 +0100
                Re: local arrays and stack glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-03-24 17:29 +0000
                  Re: local arrays and stack David Brown <david.brown@hesbynett.no> - 2015-03-24 20:01 +0100
          Re: local arrays and stack Keith Thompson <kst-u@mib.org> - 2015-03-23 08:24 -0700
            Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-23 08:42 -0700
              Re: local arrays and stack Bartc <bc@freeuk.com> - 2015-03-23 16:07 +0000
                Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-23 09:15 -0700
                Re: local arrays and stack Keith Thompson <kst-u@mib.org> - 2015-03-23 09:16 -0700
                  Re: local arrays and stack Bartc <bc@freeuk.com> - 2015-03-23 16:34 +0000
                    Re: local arrays and stack Xcott Craver <xcottcraver@gmail.com> - 2015-03-23 10:12 -0700
                      Re: local arrays and stack Bartc <bc@freeuk.com> - 2015-03-23 17:44 +0000
                        Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-23 11:47 -0700
                        Re: local arrays and stack Xcott Craver <xcottcraver@gmail.com> - 2015-03-23 12:06 -0700
                          Re: local arrays and stack Bartc <bc@freeuk.com> - 2015-03-23 20:25 +0000
                            Re: local arrays and stack Xcott Craver <xcottcraver@gmail.com> - 2015-03-23 14:10 -0700
                              Re: local arrays and stack Bartc <bc@freeuk.com> - 2015-03-23 22:22 +0000
                                Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-23 23:57 -0700
                                Re: local arrays and stack David Brown <david.brown@hesbynett.no> - 2015-03-24 10:28 +0100
                                  Re: local arrays and stack Bartc <bc@freeuk.com> - 2015-03-24 10:44 +0000
                                    Re: local arrays and stack Martin Shobe <martin.shobe@yahoo.com> - 2015-03-24 06:38 -0500
                                      Re: local arrays and stack Martin Shobe <martin.shobe@yahoo.com> - 2015-03-24 09:57 -0500
                                    Re: local arrays and stack David Brown <david.brown@hesbynett.no> - 2015-03-24 13:22 +0100
                                      Re: local arrays and stack Bartc <bc@freeuk.com> - 2015-03-25 16:07 +0000
                                        Re: local arrays and stack David Brown <david.brown@hesbynett.no> - 2015-03-25 17:42 +0100
                                          Re: local arrays and stack Bartc <bc@freeuk.com> - 2015-03-25 19:06 +0000
                                            Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-25 12:26 -0700
                                              Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-25 13:20 -0700
                                            Re: local arrays and stack Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-25 12:28 -0700
                                              Re: local arrays and stack David Brown <david.brown@hesbynett.no> - 2015-03-25 21:45 +0100
                                            Re: local arrays and stack Keith Thompson <kst-u@mib.org> - 2015-03-25 12:50 -0700
                                              Re: local arrays and stack Bartc <bc@freeuk.com> - 2015-03-25 22:33 +0000
                                                Re: local arrays and stack David Brown <david.brown@hesbynett.no> - 2015-03-25 23:57 +0100
                                            Re: local arrays and stack David Brown <david.brown@hesbynett.no> - 2015-03-25 21:42 +0100
                                        Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-25 09:55 -0700
                                        Re: local arrays and stack Keith Thompson <kst-u@mib.org> - 2015-03-25 12:36 -0700
                                          Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-25 13:04 -0700
                                          Re: local arrays and stack David Brown <david.brown@hesbynett.no> - 2015-03-25 21:52 +0100
                                            Re: local arrays and stack Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-25 15:18 -0700
                                              Re: local arrays and stack David Brown <david.brown@hesbynett.no> - 2015-03-26 00:02 +0100
                                              Re: local arrays and stack Melzzzzz <mel@zzzzz.com> - 2015-03-26 00:47 +0100
                                    Re: local arrays and stack Mel <mel@zzzzz.com> - 2015-03-24 14:58 +0100
                                Re: local arrays and stack Xcott Craver <xcottcraver@gmail.com> - 2015-03-24 06:58 -0700
                            Re: local arrays and stack Keith Thompson <kst-u@mib.org> - 2015-03-23 14:34 -0700
                            Re: local arrays and stack David Brown <david.brown@hesbynett.no> - 2015-03-24 10:16 +0100
                        Re: local arrays and stack David Brown <david.brown@hesbynett.no> - 2015-03-24 09:55 +0100
                        Re: local arrays and stack Noob <root@127.0.0.1> - 2015-03-24 10:23 +0100
                  Re: local arrays and stack Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-24 12:18 -0700
                    Re: local arrays and stack Keith Thompson <kst-u@mib.org> - 2015-03-24 13:42 -0700
                      Re: local arrays and stack Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-25 08:47 -0700
              Re: local arrays and stack Xcott Craver <xcottcraver@gmail.com> - 2015-03-23 09:32 -0700
                Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-23 09:57 -0700
                Re: local arrays and stack Keith Thompson <kst-u@mib.org> - 2015-03-23 10:37 -0700
                  Re: local arrays and stack Xcott Craver <xcottcraver@gmail.com> - 2015-03-23 10:49 -0700
                    Re: local arrays and stack Keith Thompson <kst-u@mib.org> - 2015-03-23 12:48 -0700
                      Re: local arrays and stack jt@toerring.de (Jens Thoms Toerring) - 2015-03-23 22:29 +0000
                        Re: local arrays and stack James Kuyper <jameskuyper@verizon.net> - 2015-03-23 19:03 -0400
                          Re: local arrays and stack jt@toerring.de (Jens Thoms Toerring) - 2015-03-23 23:36 +0000
                          Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-24 02:17 -0700
                  Re: local arrays and stack Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-23 11:56 -0700
            Re: local arrays and stack Robert Wessel <robertwessel2@yahoo.com> - 2015-03-23 20:00 -0500
              Re: local arrays and stack David Brown <david.brown@hesbynett.no> - 2015-03-24 10:39 +0100

Page 1 of 4  [1] 2 3 4  Next page →

#58631 — local arrays and stack

could someone clarify if local arrays (smaller or bigger onesd) are placed on stack
or no (at least in most populer c implementations)

my quick tests in mingw seem to show that arrays are not placed on stack at all
(though im not sure it were partial test
maybe it depends on some floag or what)


if so this is paradoxical a bit as
using local arrays on stack could be possibly used to spare ram memory 
(for quick and cheap alocation and
droping it) if they are not placed
on stack and there are big amount of this it superflously consumes memory

(if placed in different area there 
is also an option to place it all in the same ram buffer place - but I there am 
not sure if this is used

what with that, could someone answer this?

[toc] | [next] | [standalone]

#58633

I remember that in x86+Windows Borland C
compiler puts arrays on the stack; 
Gcc + Linux or Windows that I used, too...
I think it is better put local
array of a function in a stack, or
 the one
used for passing argument
Or some other stack

[toc] | [prev] | [next] | [standalone]

#58688

On Sunday, March 22, 2015 at 8:51:36 AM UTC, fir wrote:
>
> could someone clarify if local arrays (smaller or bigger onesd) are 
> placed on stack or no (at least in most populer c implementations)
> 
> my quick tests in mingw seem to show that arrays are not placed on stack
> at all (though im not sure it were partial test maybe it depends on some
> floag or what)
> 
It would be surprising if not.
However I usually malloc() any array over 1000 elements, to avoid
putting too much data on the stack. 
The way to test is to declare a few ints or other small variables,
and print out their addresses along with the array. That will tell
you if they're in radically different areas of memory.
 

[toc] | [prev] | [next] | [standalone]

#58721

W dniu niedziela, 22 marca 2015 21:23:00 UTC+1 użytkownik Malcolm McLean napisał:
> On Sunday, March 22, 2015 at 8:51:36 AM UTC, fir wrote:
> >
> > could someone clarify if local arrays (smaller or bigger onesd) are 
> > placed on stack or no (at least in most populer c implementations)
> > 
> > my quick tests in mingw seem to show that arrays are not placed on stack
> > at all (though im not sure it were partial test maybe it depends on some
> > floag or what)
> > 
> It would be surprising if not.
> However I usually malloc() any array over 1000 elements, to avoid
> putting too much data on the stack. 
> The way to test is to declare a few ints or other small variables,
> and print out their addresses along with the array. That will tell
> you if they're in radically different areas of memory.

I was doing some tests and as i said
it seems that here (in mingw) local arrays are not placed on stack (i may be mistakem becouse im not in the mood for
extensive tests but it seems like i said)

im curious if some other people was doing such test and how it looks like there

[toc] | [prev] | [next] | [standalone]

#58692

On Sunday, March 22, 2015 at 4:51:36 AM UTC-4, fir wrote:
> could someone clarify if local arrays (smaller or bigger onesd) are placed 
> on stack or no (at least in most populer c implementations)

It is quite common for local arrays to be placed on the stack, which is the
reason buffer overrun vulnerabilities allow attackers to take over computers:
the array is sitting in memory next to stored return addresses, which can 
be overwritten to make the program jump to malicious code.

--S

[toc] | [prev] | [next] | [standalone]

#58720

W dniu niedziela, 22 marca 2015 23:07:35 UTC+1 użytkownik Xcott Craver napisał:
> On Sunday, March 22, 2015 at 4:51:36 AM UTC-4, fir wrote:
> > could someone clarify if local arrays (smaller or bigger onesd) are placed 
> > on stack or no (at least in most populer c implementations)
> 
> It is quite common for local arrays to be placed on the stack, which is the
> reason buffer overrun vulnerabilities allow attackers to take over computers:
> the array is sitting in memory next to stored return addresses, which can 
> be overwritten to make the program jump to malicious code.
> 
it probably helps that stack grows back array filling s growing forward so going up over the top edge of array rewrites the back adress (so this is not neccessary outcome of c specifics but (also if not more) growing down stack convention) :/

anyway my quick test seem to showed that in mingw local arrays are not placed on stack (maybe im mistaken)

[toc] | [prev] | [next] | [standalone]

#58726

On Mon, 23 Mar 2015 01:50:41 -0700 (PDT), fir <profesor.fir@gmail.com>
wrote:

>W dniu niedziela, 22 marca 2015 23:07:35 UTC+1 u?ytkownik Xcott Craver napisa?:
>> On Sunday, March 22, 2015 at 4:51:36 AM UTC-4, fir wrote:
>> > could someone clarify if local arrays (smaller or bigger onesd) are placed 
>> > on stack or no (at least in most populer c implementations)
>> 
>> It is quite common for local arrays to be placed on the stack, which is the
>> reason buffer overrun vulnerabilities allow attackers to take over computers:
>> the array is sitting in memory next to stored return addresses, which can 
>> be overwritten to make the program jump to malicious code.
>> 
>it probably helps that stack grows back array filling s growing forward so going up over the top edge of array rewrites the back adress (so this is not neccessary outcome of c specifics but (also if not more) growing down stack convention) :/


It's a common misconception that an upwards growing stack is less
vulnerable to buffer overflow/stack smashing attacks.  In one limited
case that's semi-correct, where the buffer being overflowed is in the
routine that is doing the overflowing, and there is no active return
address on the stack after the overflowed buffer.  Unfortunately the
vast majority of real stack smashes use subroutines to do the dirty
work in a buffer owned by a caller.  That just moves the point at
which the bad return address is used.  Consider:

void f(void)
{
  char s[4];
  strcpy(s, "abcdefghjklmnopqrstuvwxyz");
}

With a typical downward growing stack, the smashed return address will
be the one from f().  With an upwards growing stack, it'll be the
return from strcpy() that's altered.  Not exactly a huge improvement.

And the stack growth direction doesn't do anything to prevent the
corruption of any other items in the same stack frame that are places
after the buffer in question, or any items following an overflowed
buffer anywhere in the system.  Consider what happens if the string in
the following structure is overflowed (again, assuming typical layout
in memory):

struct st {char s[4]; void (*fp)(void);};


>anyway my quick test seem to showed that in mingw local arrays are not placed on stack (maybe im mistaken)


Certainly not small ones, or in general.

[toc] | [prev] | [next] | [standalone]

#58743

W dniu poniedziałek, 23 marca 2015 10:26:30 UTC+1 użytkownik robert...@yahoo.com napisał:
> On Mon, 23 Mar 2015 01:50:41 -0700 (PDT), fir <profesor.fir@gmail.com>
> wrote:
> 
> >W dniu niedziela, 22 marca 2015 23:07:35 UTC+1 u?ytkownik Xcott Craver napisa?:
> >> On Sunday, March 22, 2015 at 4:51:36 AM UTC-4, fir wrote:
> >> > could someone clarify if local arrays (smaller or bigger onesd) are placed 
> >> > on stack or no (at least in most populer c implementations)
> >> 
> >> It is quite common for local arrays to be placed on the stack, which is the
> >> reason buffer overrun vulnerabilities allow attackers to take over computers:
> >> the array is sitting in memory next to stored return addresses, which can 
> >> be overwritten to make the program jump to malicious code.
> >> 
> >it probably helps that stack grows back array filling s growing forward so going up over the top edge of array rewrites the back adress (so this is not neccessary outcome of c specifics but (also if not more) growing down stack convention) :/
> 
> 
> It's a common misconception that an upwards growing stack is less
> vulnerable to buffer overflow/stack smashing attacks.  In one limited
> case that's semi-correct, where the buffer being overflowed is in the
> routine that is doing the overflowing, and there is no active return
> address on the stack after the overflowed buffer.  Unfortunately the
> vast majority of real stack smashes use subroutines to do the dirty
> work in a buffer owned by a caller.  That just moves the point at
> which the bad return address is used.  Consider:
> 
> void f(void)
> {
>   char s[4];
>   strcpy(s, "abcdefghjklmnopqrstuvwxyz");
> }
> 


ye youre right, (i was never yet considered those stack smashing problematcs so i hav not much thoughts here).. though the situation as above seem to be theoreticaly more rare, 
as return back form the local array level is present abaut always and such special situation as above seem to be more rare (though in practice it may be accidentally common ;/)

[besides, im not the security maniac and
i am not a member of thic club who fulminate on c thah is insecure, for me it is fun, old unix spirit, fine thing (at least interesting)]


> With a typical downward growing stack, the smashed return address will
> be the one from f().  With an upwards growing stack, it'll be the
> return from strcpy() that's altered.  Not exactly a huge improvement.
> 
> And the stack growth direction doesn't do anything to prevent the
> corruption of any other items in the same stack frame that are places
> after the buffer in question, or any items following an overflowed
> buffer anywhere in the system.  Consider what happens if the string in
> the following structure is overflowed (again, assuming typical layout
> in memory):
> 
> struct st {char s[4]; void (*fp)(void);};
> 
> 
> >anyway my quick test seem to showed that in mingw local arrays are not placed on stack (maybe im mistaken)
> 
> 
> Certainly not small ones, or in general.

do not understood.. you mean small are placed? (need some info on this all)

[toc] | [prev] | [next] | [standalone]

#58748

On Monday, March 23, 2015 at 5:26:30 AM UTC-4, robert...@yahoo.com wrote:

> And the stack growth direction doesn't do anything to prevent the
> corruption of any other items in the same stack frame that are places
> after the buffer in question, or any items following an overflowed
> buffer anywhere in the system.  Consider what happens if the string in
> the following structure is overflowed (again, assuming typical layout
> in memory):
> 
> struct st {char s[4]; void (*fp)(void);};

Yes.  The ultimate problem isn't using a stack, or the layout of the stack;
the ultimate problem is that we store code addresses in proximity to data,
where the former is used to control program flow.

It's hard to find a real-world analogy to a practice so widespread and yet
so reckless.  It would be like changing a car's controls so that the 
emergency brake and reverse gear are buttons labeled '7' and '8' right after
the stereo's 6 radio station presets.

> >anyway my quick test seem to showed that in mingw local arrays are not 
> > placed on stack (maybe im mistaken)
> 
> Certainly not small ones, or in general. 

Using clang on OSX I see arrays placed on the stack.  I write:

#define LEN 4000
int main( void ) {
        int array [LEN];


And I see it compiled to this:

a.out[0x100000ec0]:  pushq  %rbp
a.out[0x100000ec1]:  movq   %rsp, %rbp
a.out[0x100000ec4]:  subq   $0x3ea0, %rsp  <---16032 bytes

--S

[toc] | [prev] | [next] | [standalone]

#58756

W dniu poniedziałek, 23 marca 2015 15:29:50 UTC+1 użytkownik Xcott Craver napisał:
> On Monday, March 23, 2015 at 5:26:30 AM UTC-4, robert...@yahoo.com wrote:
> 
> > And the stack growth direction doesn't do anything to prevent the
> > corruption of any other items in the same stack frame that are places
> > after the buffer in question, or any items following an overflowed
> > buffer anywhere in the system.  Consider what happens if the string in
> > the following structure is overflowed (again, assuming typical layout
> > in memory):
> > 
> > struct st {char s[4]; void (*fp)(void);};
> 
> Yes.  The ultimate problem isn't using a stack, or the layout of the stack;
> the ultimate problem is that we store code addresses in proximity to data,
> where the former is used to control program flow.
> 
> It's hard to find a real-world analogy to a practice so widespread and yet
> so reckless.  It would be like changing a car's controls so that the 
> emergency brake and reverse gear are buttons labeled '7' and '8' right after
> the stereo's 6 radio station presets.
> 
> > >anyway my quick test seem to showed that in mingw local arrays are not 
> > > placed on stack (maybe im mistaken)
> > 
> > Certainly not small ones, or in general. 
> 
> Using clang on OSX I see arrays placed on the stack.  I write:
> 
> #define LEN 4000
> int main( void ) {
>         int array [LEN];
> 
> 
> And I see it compiled to this:
> 
> a.out[0x100000ec0]:  pushq  %rbp
> a.out[0x100000ec1]:  movq   %rsp, %rbp
> a.out[0x100000ec4]:  subq   $0x3ea0, %rsp  <---16032 bytes
> 
> --S

whats that adres so high 0x100000ec0 , (this is over 32 bit value)

[toc] | [prev] | [next] | [standalone]

#58811

On Mon, 23 Mar 2015 07:29:42 -0700 (PDT), Xcott Craver
<xcottcraver@gmail.com> wrote:

>On Monday, March 23, 2015 at 5:26:30 AM UTC-4, robert...@yahoo.com wrote:
>
>> And the stack growth direction doesn't do anything to prevent the
>> corruption of any other items in the same stack frame that are places
>> after the buffer in question, or any items following an overflowed
>> buffer anywhere in the system.  Consider what happens if the string in
>> the following structure is overflowed (again, assuming typical layout
>> in memory):
>> 
>> struct st {char s[4]; void (*fp)(void);};
>
>Yes.  The ultimate problem isn't using a stack, or the layout of the stack;
>the ultimate problem is that we store code addresses in proximity to data,
>where the former is used to control program flow.
>
>It's hard to find a real-world analogy to a practice so widespread and yet
>so reckless.  It would be like changing a car's controls so that the 
>emergency brake and reverse gear are buttons labeled '7' and '8' right after
>the stereo's 6 radio station presets.


Not really, the problem is that buffers can overflow.  Your car radio
analogy would be more like hitting the "next preset" button on the
radio when you're already at #6, and having it shift the transmission.

[toc] | [prev] | [next] | [standalone]

#58831

W dniu poniedziałek, 23 marca 2015 15:29:50 UTC+1 użytkownik Xcott Craver napisał:
> a.out[0x100000ec4]:  subq   $0x3ea0, %rsp  <---16032 bytes


this may be only evidence of lazy compiler,
making stack data avaliable is not only 
1) substracting the expected amount from stack pointer but also 
2) making sure that given range ram area is unocuppied/avaliable [there may be a biggest problem here]
3) pin up physical pages

[toc] | [prev] | [next] | [standalone]

#58832

W dniu wtorek, 24 marca 2015 12:01:56 UTC+1 użytkownik fir napisał:
> W dniu poniedziałek, 23 marca 2015 15:29:50 UTC+1 użytkownik Xcott Craver napisał:
> > a.out[0x100000ec4]:  subq   $0x3ea0, %rsp  <---16032 bytes
> 
> 
> this may be only evidence of lazy compiler,
> making stack data avaliable is not only 
> 1) substracting the expected amount from stack pointer but also 
> 2) making sure that given range ram area is unocuppied/avaliable [there may be a biggest problem here]
> 3) pin up physical pages

PS after those answers here i got confused it didnt cleared to much ;c

 i made some test like changing fragment of the linker commandline to

 -Wl,--subsystem,windows,--stack,100000000 

and it showed that stack was moved from 
the begining area of adress space (first 4 MB seem to be beginning area as program is loaded at 4MB adres) to the place after the program image (in this case 100 MB after so overfilling of the stack would yeild to overvrite of its end sections

so it seems that stack size is compile time settable (can be set quite big)

(though default here (old xp) is 1 MB or 2MB it is quite _few_ you dont seem to have option to alloc 3 MB local array on stack in this situation) 

and does not seem like it will be growable (quessing form some text in this thread if will not complain on stack pointer subtraction but will get crash on
acces), what damn __ms_something is doing i still dont know

[toc] | [prev] | [next] | [standalone]

#58834

On 24/03/15 12:01, fir wrote:
> W dniu poniedziałek, 23 marca 2015 15:29:50 UTC+1 użytkownik Xcott Craver napisał:
>> a.out[0x100000ec4]:  subq   $0x3ea0, %rsp  <---16032 bytes
> 
> 
> this may be only evidence of lazy compiler,
> making stack data avaliable is not only 
> 1) substracting the expected amount from stack pointer but also 

Yes.

> 2) making sure that given range ram area is unocuppied/avaliable [there may be a biggest problem here]

No.

It is the OS's task to ensure that the stack given to the program is in
ram that does not overlap or collide with other memory.

> 3) pin up physical pages
> 

No, that is certainly not the responsibility of the compiler!  Again, it
is the OS (along with the MMU) that is responsible for the memory mapping.

Of course, an OS may decide that the size of a program's stack is fixed,
or require some additional calls (like __chkstk_ms) to change the stack
size.  But the /compiler/ does not determine the memory mapping.

[toc] | [prev] | [next] | [standalone]

#58855

David Brown <david.brown@hesbynett.no> wrote:
> On 24/03/15 12:01, fir wrote:
 
(snip)

>> 2) making sure that given range ram area is unocuppied/avaliable 
>>    [there may be a biggest problem here]
 
> No.
 
> It is the OS's task to ensure that the stack given to the program 
> is in ram that does not overlap or collide with other memory.

I don't believe that the "definition of OS" includes that statement.
It is nice of an OS to do that, and good ones might.

A system with protected memory has to protect each task from others,
but not from itself.
 
>> 3) pin up physical pages
 
> No, that is certainly not the responsibility of the compiler!  
> Again, it is the OS (along with the MMU) that is responsible 
> for the memory mapping.

So not required on systems without an MMU?
 
> Of course, an OS may decide that the size of a program's stack is fixed,
> or require some additional calls (like __chkstk_ms) to change the stack
> size.  But the /compiler/ does not determine the memory mapping.

And the compiler/linker might decide that the stack size is fixed.
It is then the responsibility of the program to stay within that size.

-- glen

[toc] | [prev] | [next] | [standalone]

#58862

On 24/03/15 18:29, glen herrmannsfeldt wrote:
> David Brown <david.brown@hesbynett.no> wrote:
>> On 24/03/15 12:01, fir wrote:
>
> (snip)
>
>>> 2) making sure that given range ram area is unocuppied/avaliable
>>>     [there may be a biggest problem here]
>
>> No.
>
>> It is the OS's task to ensure that the stack given to the program
>> is in ram that does not overlap or collide with other memory.
>
> I don't believe that the "definition of OS" includes that statement.
> It is nice of an OS to do that, and good ones might.

In the context of the systems under discussion here (Linux and Windows), 
the OS does that.  But you are right - while it is an expected part of a 
"big" OS that keeps tasks carefully separated, it will certainly not be 
the case in small embedded OS's.

>
> A system with protected memory has to protect each task from others,
> but not from itself.

The OS is given a higher level of trust - tasks are "protected" from the 
OS in that they can expect the OS code to behave correctly.  But the OS 
and other tasks need protected from user-level tasks because they should 
continue to work even if a task misbehaves.

(Again, this does not apply in cases where there is no memory protection 
hardware, or in a small embedded where /all/ tasks are expected to 
behave correctly.)

>
>>> 3) pin up physical pages
>
>> No, that is certainly not the responsibility of the compiler!
>> Again, it is the OS (along with the MMU) that is responsible
>> for the memory mapping.
>
> So not required on systems without an MMU?

In the case of Linux/Windows, yes.

>
>> Of course, an OS may decide that the size of a program's stack is fixed,
>> or require some additional calls (like __chkstk_ms) to change the stack
>> size.  But the /compiler/ does not determine the memory mapping.
>
> And the compiler/linker might decide that the stack size is fixed.
> It is then the responsibility of the program to stay within that size.
>

It might add additional limits, but usually (at least when possible on 
the target cpu and OS) it is more efficient for the compiler-generated 
code to act as though the stack is unlimited, and for the MMU (or on 
some cpus, a stack limit register) to handle out-of-bounds errors.

[toc] | [prev] | [next] | [standalone]

#58754

Robert Wessel <robertwessel2@yahoo.com> writes:
> On Mon, 23 Mar 2015 01:50:41 -0700 (PDT), fir <profesor.fir@gmail.com>
> wrote:
[...]
>>anyway my quick test seem to showed that in mingw local arrays are not
>>placed on stack (maybe im mistaken)
>
> Certainly not small ones, or in general.

Hmm?

MinGW uses gcc as its compiler.  As far as I know, all local non-static
objects (i.e., objects with automatic storage duration), including
arrays of any size, are allocated on the stack.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#58757

W dniu poniedziałek, 23 marca 2015 16:24:12 UTC+1 użytkownik Keith Thompson napisał:
> Robert Wessel <robertwessel2@yahoo.com> writes:
> > On Mon, 23 Mar 2015 01:50:41 -0700 (PDT), fir <profesor.fir@gmail.com>
> > wrote:
> [...]
> >>anyway my quick test seem to showed that in mingw local arrays are not
> >>placed on stack (maybe im mistaken)
> >
> > Certainly not small ones, or in general.
> 
> Hmm?
> 
> MinGW uses gcc as its compiler.  As far as I know, all local non-static
> objects (i.e., objects with automatic storage duration), including
> arrays of any size, are allocated on the stack.
> 
any size?

 i thought that large ones are 'silently' moved to static area (stack is small, probably 2MB limit usually so how it could contain larger arrays? it could be silent move out of stack or compile error) (i may be mistaken here))

[toc] | [prev] | [next] | [standalone]

#58758

On 23/03/2015 15:42, fir wrote:
> W dniu poniedziałek, 23 marca 2015 16:24:12 UTC+1 użytkownik Keith Thompson napisał:

>> MinGW uses gcc as its compiler.  As far as I know, all local non-static
>> objects (i.e., objects with automatic storage duration), including
>> arrays of any size, are allocated on the stack.
>>
> any size?
>
>   i thought that large ones are 'silently' moved to static area (stack is small, probably 2MB limit usually so how it could contain larger arrays? it could be silent move out of stack or compile error) (i may be mistaken here))

The stack can grow. Large local arrays can also be allocated on the 
heap. It's up to the compiler.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#58759

W dniu poniedziałek, 23 marca 2015 17:07:48 UTC+1 użytkownik Bart napisał:
> On 23/03/2015 15:42, fir wrote:
> > W dniu poniedziałek, 23 marca 2015 16:24:12 UTC+1 użytkownik Keith Thompson napisał:
> 
> >> MinGW uses gcc as its compiler.  As far as I know, all local non-static
> >> objects (i.e., objects with automatic storage duration), including
> >> arrays of any size, are allocated on the stack.
> >>
> > any size?
> >
> >   i thought that large ones are 'silently' moved to static area (stack is small, probably 2MB limit usually so how it could contain larger arrays? it could be silent move out of stack or compile error) (i may be mistaken here))
> 
> The stack can grow. Large local arrays can also be allocated on the 
> heap. It's up to the compiler.
> 
on my xp stack seem to be initially like 12kb and can grow bot possibly till 2MB, not sure if more ;c

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web