From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,a59c0afeb6808e51 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-09-03 04:20:27 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!cyclone.bc.net!news-out.newsfeeds.com!propagator2-maxim!propagator-maxim!news-in.spamkiller.net!usc.edu!attla2!ip.att.net!attbi_feed3!attbi.com!rwcrnsc51.ops.asp.att.net.POSTED!not-for-mail From: "Jeffrey Creem" Newsgroups: comp.lang.ada References: <1f358d66.0208302358.6f1c6a39@posting.google.com> <87y9an5tt2.fsf@deneb.enyo.de> <1f358d66.0209020705.6769d948@posting.google.com> <0DMc9.5002$YN.1223639060@newssvr30.news.prodigy.com> Subject: Re: Howto debug seg-faulting Ada 95 code? X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <_V0d9.120646$_91.183808@rwcrnsc51.ops.asp.att.net> NNTP-Posting-Host: 66.31.5.146 X-Complaints-To: abuse@attbi.com X-Trace: rwcrnsc51.ops.asp.att.net 1031052026 66.31.5.146 (Tue, 03 Sep 2002 11:20:26 GMT) NNTP-Posting-Date: Tue, 03 Sep 2002 11:20:26 GMT Organization: AT&T Broadband Date: Tue, 03 Sep 2002 11:20:26 GMT Xref: archiver1.google.com comp.lang.ada:28691 Date: 2002-09-03T11:20:26+00:00 List-Id: "Pat Rogers" wrote in message news:asSc9.5091$Ss7.1261527110@newssvr30.news.prodigy.com... > > > > Having said that, every compiler I have used does something like > this. It > > also tends to > > make intuitive sense. > > Humm, every compiler I have used did not. Declarations within library > units are just the first things pushed. We don't think of that initial > stack push as being a stack operation because it is never "popped" > until the program completes. > > Well, as I said there is nothing in the LRM that I know of that requires either behaviour so it is certainly possible that you are correct. Another poster was more precise when he said he sees x86 compilers put these in the data segment (initialized or uninitiazed). The compiler I have seen which put package level variables "not on the stack" are VADS -> 68K vxWorks VADS -> MIPS vxWorks VADS -> PowerPC vxWorks Apex -> Solaris GNAT -> Solaris GNAT -> win32/linux It seems like a strange convention to allocate package level variables on the stack. It now means that in a multi-tasking program you have tasks mucking in the stack of another task.... Again, no reason that I can think of that this would not work but it does feel odd.