Why was Intel a no-show on No Execute?

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

In comp.arch Yousuf Khan <bbbl67@ezrs.com> wrote:
> Sander Vesik <sander@haldjas.folklore.ee> wrote:
> >> The only place you can run code is from the code segment. If you
> >> insert code
> >
> > only superficialy true. as you have control of the stack, you can
> > cause any number of function calls to happen with the parameters of
> > your choice. This is essentialy the same as running code.
>
> I see, so how long has C been passing command-line parameters through the
> stack? How many other languages do this?

This has always been so, except possibly on some obscure architectures
(obscure from the POV of C language).

>
> Yousuf Khan
>
>

--
Sander

+++ Out of cheese error +++

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Sander Vesik <sander@haldjas.folklore.ee> writes:
>In comp.arch Yousuf Khan <bbbl67@ezrs.com> wrote:
>> I see, so how long has C been passing command-line parameters through the
>> stack? How many other languages do this?
>
>This has always been so, except possibly on some obscure architectures
>(obscure from the POV of C language).

C programs have always gotten their command-line parameters through
the first two parameters of main(); where these parameters are passed
depends on the calling convention; often it is registers.

Where the strings pointed to by argv[] are located depends on the OS
and has little to do with C.

Followups to comp.arch.

- anton
--
M. Anton Ertl Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

In comp.sys.ibm.pc.hardware.chips Sander Vesik <sander@haldjas.folklore.ee> wrote:
> So you have no idea at all what a exception is in C++ / Java ? If so

And just _how_ does an exception occur? At the hw layer, because
this is a hw group. Either some code signals it, which is a library
and potentially kernel event, or some hw event (always kernel).
The kernel can always have fixup code, even to the point of allowing
faults in libspace.

Hmm ... gives me another idea: Maybe the libs can be fixed?!?
Something like:
gets():
mov edx, [esp] ; save return addr in edx
; blah blah gets() code
cmp edx, [esp] ; check that stack not trampled
jnz trampled ; (could be more sophisticated stack sig)
ret
trampled:
printk("Stack trampled by gets() input")
call exit


> why are you arguing on this topic? You are only going to be completely
> wrong and embarass yourself.

My, my, aren't you hot under the collar. Obviously upset.
Something I've learned is often related to a lack of confidence.

-- Robert

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

In article <Fzruc.3321$SE6.1965@newssvr22.news.prodigy.com>,
Robert Redelmeier <redelm@ev1.net.invalid> wrote:

> In comp.sys.ibm.pc.hardware.chips Sander Vesik <sander@haldjas.folklore.ee>
> wrote:
> > So you have no idea at all what a exception is in C++ / Java ? If so
>
> And just _how_ does an exception occur? At the hw layer, because
> this is a hw group. Either some code signals it, which is a library
> and potentially kernel event, or some hw event (always kernel).
> The kernel can always have fixup code, even to the point of allowing
> faults in libspace.

This is getting embarassing. Could it really be true that you have no
idea what "exception" means in the context of C++ or Java?

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

In article <christian.bau-85EE9D.23362630052004@slb-
newsm1.svr.pol.co.uk>, christian.bau@cbau.freeserve.co.uk says...
> In article <Fzruc.3321$SE6.1965@newssvr22.news.prodigy.com>,
> Robert Redelmeier <redelm@ev1.net.invalid> wrote:
>
> > In comp.sys.ibm.pc.hardware.chips Sander Vesik <sander@haldjas.folklore.ee>
> > wrote:
> > > So you have no idea at all what a exception is in C++ / Java ? If so
> >
> > And just _how_ does an exception occur? At the hw layer, because
> > this is a hw group. Either some code signals it, which is a library
> > and potentially kernel event, or some hw event (always kernel).
> > The kernel can always have fixup code, even to the point of allowing
> > faults in libspace.
>
> This is getting embarassing. Could it really be true that you have no
> idea what "exception" means in the context of C++ or Java?

Rather than being a little argumentative prig, why don't you
educate us?

--
Keith

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

In comp.sys.ibm.pc.hardware.chips Christian Bau <christian.bau@cbau.freeserve.co.uk> wrote:
> This is getting embarassing. Could it really be true that you have
> no idea what "exception" means in the context of C++ or Java?

Could it be really true that you're not embarrased by stooping
to "ad hominem"? Or content-free posts? I have an idea, and am
hardly embarrassed by not knowing more of Java or C++. Cruftspace,
IMHO. You will note by my quote line that I read in csiphc.

What I know of exceptions is they appear to have been created
for error checking. Java and C++ seem to have vastly different
mechanisms (runtime vs compile time) that doubtless has resulted in
juvenile flame-fests. Clever programmer probably have been able
to [ab]use these mechanisms for other purposes [multithreading?].
Overloaded, if you will

Actually, comparing hw & memory return addr's won't work for
a totally different reason -- gets() and it's evil siblings
are almost certainly blocking syscalls. A task switch to a
different process is likely and the hw stack will be flooded.

Better to save/fingerprint the stack on entry and abort
if trampled as I explain elsewhere.

-- Robert

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

In comp.arch Robert Redelmeier <redelm@ev1.net.invalid> wrote:
> In comp.sys.ibm.pc.hardware.chips Sander Vesik <sander@haldjas.folklore.ee> wrote:
> > So you have no idea at all what a exception is in C++ / Java ? If so
>
> And just _how_ does an exception occur? At the hw layer, because
> this is a hw group. Either some code signals it, which is a library
> and potentially kernel event, or some hw event (always kernel).

There are no specific hw event involved at all. Again, simply go
and read up on what exceptions are.

> The kernel can always have fixup code, even to the point of allowing
> faults in libspace.

The kernel would not know anything about the exception.

[snip]

>
> > why are you arguing on this topic? You are only going to be completely
> > wrong and embarass yourself.
>
> My, my, aren't you hot under the collar. Obviously upset.
> Something I've learned is often related to a lack of confidence.

No I simply have short temper with those who continue rambling on
even when they have obviously no clue.

>
> -- Robert
>

--
Sander

+++ Out of cheese error +++

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

On Sun, 30 May 2004, Yousuf Khan wrote:

> > Google for ingo molnar, execshield, ascii armou?r.
>
> Looks like he was using the segment limits to protect against stack
> overflows.

Not quite. To compensate for the lack of write-but-not-execute and
execute-but-not-write modes for the pages.

-Peter

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

In comp.sys.ibm.pc.hardware.chips Sander Vesik <sander@haldjas.folklore.ee> wrote:
> No I simply have short temper with those who continue
> rambling on even when they have obviously no clue.

A short temper is a shortcoming in itself. It must hurt you.
If cluelessness is obvious, why add to the discussion?
Neither you nor anyone else is appointed the USENET police
to correct all postings.

-- Robert

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Peter "Firefly" Lund <firefly@diku.dk> wrote:
> On Sun, 30 May 2004, Yousuf Khan wrote:
>
>>> Google for ingo molnar, execshield, ascii armou?r.
>>
>> Looks like he was using the segment limits to protect against stack
>> overflows.
>
> Not quite. To compensate for the lack of write-but-not-execute and
> execute-but-not-write modes for the pages.

Well, so what did I say that was "not quite"?

Yousuf Khan

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

On Sun, 30 May 2004, Robert Redelmeier wrote:

> a totally different reason -- gets() and it's evil siblings
> are almost certainly blocking syscalls. A task switch to a
> different process is likely and the hw stack will be flooded.

Since most operating systems these days have preemptive multitasking, you
will need to save/restore the hw stack in the context switch function
inside the OS anyway, won't you?

Oh, and have some mechanism that stops the hw stack from getting updated
in supervisor mode?

Or have /two/ hw stacks, so supervisor mode doesn't slow down?

> Better to save/fingerprint the stack on entry and abort
> if trampled as I explain elsewhere.

Yes, much better solution.

Aren't all OpenBSD utilities compiled with stack canaries, these days?

-Peter

PS: They are right, you really don't know anything about exception
handling in C++, Java, ML, Haskell, ...

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

In comp.sys.ibm.pc.hardware.chips "Peter \"Firefly\" Lund" <firefly@diku.dk> wrote:
> Since most operating systems these days have preemptive multitasking, you
> will need to save/restore the hw stack in the context switch function
> inside the OS anyway, won't you?

Unfortunately, the hw stack is programmer inaccessible AFAIK.
Just a part of the branch prediction mechanism.

Unworkable as a hw solution to buffer overflows
ins gets() amost certainly will cause a task swap.

-- Robert

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

In article <MPG.1b243eb96eb82da498992b@news1.news.adelphia.net>,
KR Williams <krw@att.biz> wrote:

> In article <christian.bau-85EE9D.23362630052004@slb-
> newsm1.svr.pol.co.uk>, christian.bau@cbau.freeserve.co.uk says...
> > In article <Fzruc.3321$SE6.1965@newssvr22.news.prodigy.com>,
> > Robert Redelmeier <redelm@ev1.net.invalid> wrote:
> >
> > > In comp.sys.ibm.pc.hardware.chips Sander Vesik
> > > <sander@haldjas.folklore.ee>
> > > wrote:
> > > > So you have no idea at all what a exception is in C++ / Java ? If so
> > >
> > > And just _how_ does an exception occur? At the hw layer, because
> > > this is a hw group. Either some code signals it, which is a library
> > > and potentially kernel event, or some hw event (always kernel).
> > > The kernel can always have fixup code, even to the point of allowing
> > > faults in libspace.
> >
> > This is getting embarassing. Could it really be true that you have no
> > idea what "exception" means in the context of C++ or Java?
>
> Rather than being a little argumentative prig, why don't you
> educate us?


There are plenty of documents around on the internet. There is a draft
specification of the C++ Standard available for free, which will explain
C++ exceptions. And at www.sun.com you will find both the Java Language
Specification and the Java Virtual Machine Specification, both available
for free, which you can download and educate yourself.

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Christian Bau wrote:
> In article <MPG.1b243eb96eb82da498992b@news1.news.adelphia.net>,
> KR Williams <krw@att.biz> wrote:

[SNIP]

>>Rather than being a little argumentative prig, why don't you
>>educate us?
>
>
>
> There are plenty of documents around on the internet. There is a draft
> specification of the C++ Standard available for free, which will explain
> C++ exceptions. And at www.sun.com you will find both the Java Language
> Specification and the Java Virtual Machine Specification, both available
> for free, which you can download and educate yourself.

ROTFL, it never rains but it pours, eh Keith ?

I take it that you still haven't visited the "irrelevant" OpenGL.org
yet, or followed up the van Dam refs I gave you...

FWIW think C.Bau is being much harsher than I, the C++ standard is a
--ing tome++ and it was full of thinkos, errors and contradictions.
Despite that it is nigh-on essential reading if you're going to look
at exceptions. Sigh, about time I re-read bits of it myself. 🙁

Cheers,
Rupert

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

In article <1085997404.339124@teapot.planet.gong>, roo@try-
removing-this.darkboong.demon.co.uk says...
> Christian Bau wrote:
> > In article <MPG.1b243eb96eb82da498992b@news1.news.adelphia.net>,
> > KR Williams <krw@att.biz> wrote:
>
> [SNIP]
>
> >>Rather than being a little argumentative prig, why don't you
> >>educate us?
> >
> >
> >
> > There are plenty of documents around on the internet. There is a draft
> > specification of the C++ Standard available for free, which will explain
> > C++ exceptions. And at www.sun.com you will find both the Java Language
> > Specification and the Java Virtual Machine Specification, both available
> > for free, which you can download and educate yourself.
>
> ROTFL, it never rains but it pours, eh Keith ?

You think I worry about your lame "discussions"?

> I take it that you still haven't visited the "irrelevant" OpenGL.org
> yet, or followed up the van Dam refs I gave you...

No, and I have not intention of doing so anytime soon. Because
you think I should trudge through code that I likely wouldn't
understand doesn't mean those are my marching orders.

> FWIW think C.Bau is being much harsher than I, the C++ standard is a
> --ing tome++ and it was full of thinkos, errors and contradictions.
> Despite that it is nigh-on essential reading if you're going to look
> at exceptions. Sigh, about time I re-read bits of it myself. 🙁

Harsher? No, simply just as full of himself as are you. The
purpose of these forums is to educate and be educated. You two
are too full of yourselves to do the former. Why are you here?
....just to prove how much smarter you are than some simple
hardware dweebs? The arrogance is unbelievable. Personally, I
don't much care about this particular discussion, but would have
appreciated a hint a little deeper then "I'm right, go look it
up, you're too stupid to understand" attitude we're getting from
you two. No, this sort of thing isn't on my bed time reading
list.

--
Keith

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

On Mon, 31 May 2004, Robert Redelmeier wrote:

> In comp.sys.ibm.pc.hardware.chips "Peter \"Firefly\" Lund" <firefly@diku.dk> wrote:
> > Since most operating systems these days have preemptive multitasking, you
> > will need to save/restore the hw stack in the context switch function
> > inside the OS anyway, won't you?
>
> Unfortunately, the hw stack is programmer inaccessible AFAIK.
> Just a part of the branch prediction mechanism.

Yes, but you were going to change that anyway, weren't you?

(or was it somebody else's idea? I forget already)

> Unworkable as a hw solution to buffer overflows
> ins gets() amost certainly will cause a task swap.

How often do you read from stdin in a server or root program? Well, with
CGI, but isn't that just about it?

Most buffer overflows don't happen where the I/O takes place, I think.
(this is backed by regular reading about unix/linux security holes for
years on lwn.net)

Besides, stdio is buffered so not every call to gets() leads to a system
call. Far from it, in fact, unles you are reading something a human
types, as s/h/it types it.

-Peter

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

On Mon, 31 May 2004, Yousuf Khan wrote:

> Peter "Firefly" Lund <firefly@diku.dk> wrote:
> > On Sun, 30 May 2004, Yousuf Khan wrote:
> >
> >>> Google for ingo molnar, execshield, ascii armou?r.
> >>
> >> Looks like he was using the segment limits to protect against stack
> >> overflows.
> >
> > Not quite. To compensate for the lack of write-but-not-execute and
> > execute-but-not-write modes for the pages.
>
> Well, so what did I say that was "not quite"?

"not quite" was a polite way of saying "not really".

-Peter

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Did you say "stack fragmentation" and
"argument stack" and "linkage stack"?

1st) There is only one stack, every thing goes
on it.

2nd) The "stack" is linear, controlled by a single
pointer(ESP), there is no way to have fragmentation.

"Rob Warnock" <rpw3@rpw3.org> wrote in message
news:_NydnRLwMPR32STdRVn-uQ@speakeasy.net...
> Toby Thain <toby@telegraphics.com.au> wrote:
> +---------------
> | Robert Redelmeier <redelm@ev1.net.invalid> wrote:
> | > I don't think it's _required_ by any standard that local vars are
> | > allocated on the stack, but it sure makes memory managment easy.
> |
> | It also facilitates recursion and re-entrancy. But it needn't be the
> | same stack as the return linkage pointer.
> +---------------
>
> But if you *don't* do it, then you have trouble with stack fragmentation
> and/or collisions with your "argument stack" expanding at a different rate
> than your "linkage stack", resulting in one or the other bumping into
> arbitrary limits at inconvenient times. As a result, one or the other
> of the stacks gets pushed off into the heap (usually the argument stack)
> as a linked list of stack-allocated "malloc()" blocks [optimized by
> allocating a bunch at a time], which puts a lot of stress on "malloc()",
> or gets pushed into a separately-managed segment of address space, which
> puts pressure on memory allocation in general and the dynamic loader in
> particular.
>
> We had some of these issues with the Am29000 Subroutine Calling Standard
> (circa 1987), which had both a "register cache" stack for linkage
> information and "small" arguments (which were passed in registers)
> and a "memory" stack for "large" arguments (as well as *any* argument,
> regardless of size, that the called subroutine referenced by address).[1]
> Had the 29k CPU family ever made it into the 32-bit Unix[2] workstation
> market, where as we know address space layout has become an issue
> (especially with an ever-larger number of DLLs or DSOs competing for
space),
> the two-stack calling sequence could have become quite problematic.
> [As it was, in the embedded-processor space it was pretty much a
non-issue.]
>
>
> -Rob
>
> [1] Actually, the rule was that the first 16 *words* of arguments got
> passed in registers and any further words of arguments got passed
> on the memory stack, except that if the called routine referenced
> any of the first 16 words by address (e.g., "&foo") then that word
> and all subsequence words of the register args would get copied into
> the memory stack at subroutine entry. Yes, this meant that whenever
> the memory stack got used at all there was a 64-byte area at the
> front reserved in case the first 16 words needed to be manifested
> in memory. (*Ugh*)
>
> [2] Both BSD and System-V ports were done to the Am29000 -- both were
> quite straightforward since the 29k was a friendly target
enviroment --
> but shortly after both were up & running AMD chose not to promote
> the 29k as a Unix engine, and they were abandoned.
>
> -----
> Rob Warnock <rpw3@rpw3.org>
> 627 26th Avenue <URL:http://rpw3.org/>
> San Mateo, CA 94403 (650)572-2607
>

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

In comp.arch Robert Redelmeier <redelm@ev1.net.invalid> wrote:
> In comp.sys.ibm.pc.hardware.chips Sander Vesik <sander@haldjas.folklore.ee> wrote:
> > No I simply have short temper with those who continue
> > rambling on even when they have obviously no clue.
>
> A short temper is a shortcoming in itself. It must hurt you.
> If cluelessness is obvious, why add to the discussion?
> Neither you nor anyone else is appointed the USENET police
> to correct all postings.

I don't believe I need an appointment for it.

>
> -- Robert
>

--
Sander

+++ Out of cheese error +++

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

KR Williams wrote:
> In article <1085997404.339124@teapot.planet.gong>, roo@try-
> removing-this.darkboong.demon.co.uk says...
>
>>Christian Bau wrote:
>>
>>>In article <MPG.1b243eb96eb82da498992b@news1.news.adelphia.net>,
>>> KR Williams <krw@att.biz> wrote:
>>
>>[SNIP]
>>
>>
>>>>Rather than being a little argumentative prig, why don't you
>>>>educate us?

I didn't notice that this was cross-posted alt.flame come to think
of it. 😉

>>>There are plenty of documents around on the internet. There is a draft
>>>specification of the C++ Standard available for free, which will explain
>>>C++ exceptions. And at www.sun.com you will find both the Java Language
>>>Specification and the Java Virtual Machine Specification, both available
>>>for free, which you can download and educate yourself.
>>
>>ROTFL, it never rains but it pours, eh Keith ?
>
>
> You think I worry about your lame "discussions"?

Not really because you don't actually participate in them. I am
a little concerned when you cross-post vitriol though. In this case
Bau is quite correct : the relevent stuff is freely available in the
standard, and it's --ing huge. Not really something you can condense
easily, better that the guy goes away, digests it then comes back
with some new material to discuss.

>>I take it that you still haven't visited the "irrelevant" OpenGL.org
>>yet, or followed up the van Dam refs I gave you...
>
>
> No, and I have not intention of doing so anytime soon. Because
> you think I should trudge through code that I likely wouldn't
> understand doesn't mean those are my marching orders.

That's a shame because I specifically chose them because they are
aimed at folks who are competant hard/soft types but don't have an
in depth knowledge of the topic. I found the van Dam book to be a
very useful primer myself.

>>FWIW think C.Bau is being much harsher than I, the C++ standard is a
>>--ing tome++ and it was full of thinkos, errors and contradictions.
>>Despite that it is nigh-on essential reading if you're going to look
>>at exceptions. Sigh, about time I re-read bits of it myself. 🙁
>
>
> Harsher? No, simply just as full of himself as are you. The
> purpose of these forums is to educate and be educated. You two

The vast majority of USENET does not fit that model, comp.arch
has never really has been a spoon-feed group, although Mashey was
pretty good at it.

> are too full of yourselves to do the former. Why are you here?
> ...just to prove how much smarter you are than some simple
> hardware dweebs? The arrogance is unbelievable. Personally, I

No. I find it a bit bizarre that on the on hand you assert that
these groups are for facilitating education, yet on the other
hand you dismiss the use of references. Education does not
exclusively consist of being spoon-fed regurgitated text. IMO
that wastes everyone's time.

> don't much care about this particular discussion, but would have
> appreciated a hint a little deeper then "I'm right, go look it
> up, you're too stupid to understand" attitude we're getting from
> you two. No, this sort of thing isn't on my bed time reading
> list.

It's a stock response in the *hardware* orientated comp.arch. In
truth it's become a lot tamer than it was, but they generally do
not really appreciate having to regurgitate stuff that is freely
available, why the hell should folks get spoon-fed ?

Cheers,
Rupert

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

spinlock <NullVoid@att.net> wrote:
+---------------
| Did you say "stack fragmentation" and "argument stack" and "linkage stack"?
+---------------

Yes, exactly so!

+---------------
| 1st) There is only one stack, every thing goes on it.
|
| 2nd) The "stack" is linear, controlled by a single
| pointer(ESP), there is no way to have fragmentation.
+---------------

Not in the Am29000 CPU family!! The linkage, register spill/fill, and
"small argument" stack pointer was register GR1, and the "large argument"
(and any addressed arguments) stack pointer was register MSP [a.k.a. GR125].

And there have certainly been other machines which didn't use single
linear stacks, e.g., early IBM S/360 code which statically allocated
register save blocks in the callers, which the callees dynamically
linked and unlinked (with back-pointers) without moving or "growing"
anything. The call stack was this a singly-linked list of static blocks
randomly scattered all over memory. [Yes, this did *not* support
recursive routines! At least, not this default linkage.]


-Rob

-----
Rob Warnock <rpw3@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

On Fri, 28 May 2004 15:48:29 GMT in comp.arch, Robert Redelmeier
<redelm@ev1.net.invalid> wrote:

>In comp.sys.ibm.pc.hardware.chips Sander Vesik <sander@haldjas.folklore.ee> wrote:
>> Consider a user mode threads package that uses
>> get/setcontext() or setjmp / longjmp and so on.
>
>Well, I'm not entirely sure how these constructs are
>implemented by the compilers, but I would expect a
>simple `jmp` instruction. This does NOT disturb the
>hw call/ret stack, nor pose any buffer-overflow danger.

longjmp resets the registers from the jmpbuf (except returned result
value is changed to longjmp argument) including stack and frame
pointers and returns as if from the earlier setjmp call, but with a
different returned result value.

--
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada

Brian.Inglis@CSi.com (Brian dot Inglis at SystematicSw dot ab dot ca)
fake address use address above to reply

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

In article <co-dnW_qYs4tbybdRVn-jw@speakeasy.net>,
Rob Warnock <rpw3@rpw3.org> wrote:
>
>And there have certainly been other machines which didn't use single
>linear stacks, e.g., early IBM S/360 code which statically allocated
>register save blocks in the callers, which the callees dynamically
>linked and unlinked (with back-pointers) without moving or "growing"
>anything. The call stack was this a singly-linked list of static blocks
>randomly scattered all over memory. [Yes, this did *not* support
>recursive routines! At least, not this default linkage.]

Sorry, Rob, but that is completely wrong. Yes, it allowed recursive
routines, in at least three separate ways, all of which were used.
There was no requirement for the save areas to be static.


Regards,
Nick Maclaren.

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Nick Maclaren <nmm1@cus.cam.ac.uk> wrote:
+---------------
| Rob Warnock <rpw3@rpw3.org> wrote:
| >And there have certainly been other machines which didn't use single
| >linear stacks, e.g., early IBM S/360 code which statically allocated
| >register save blocks in the callers, which the callees dynamically
| >linked and unlinked (with back-pointers) without moving or "growing"
| >anything. The call stack was this a singly-linked list of static blocks
| >randomly scattered all over memory. [Yes, this did *not* support
| >recursive routines! At least, not this default linkage.]
|
| Sorry, Rob, but that is completely wrong. Yes, it allowed recursive
| routines, in at least three separate ways, all of which were used.
| There was no requirement for the save areas to be static.
+---------------

Sorry, I guess I misspoke. I didn't mean to imply that there was any
*requirement* for the save areas to be static, only that it was permitted
(if recursion wasn't needed). And for some programmers (at least, around
the shops where I was first exposed to S/360 code) it was their default
coding style, and that if you did that the resulting stack was therefore
non-linear (discontinuous).


-Rob

-----
Rob Warnock <rpw3@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

In article <9vGdnY_Cucj5oiHdRVn-sA@speakeasy.net>,
rpw3@rpw3.org (Rob Warnock) writes:
|> Nick Maclaren <nmm1@cus.cam.ac.uk> wrote:
|> +---------------
|> | Rob Warnock <rpw3@rpw3.org> wrote:
|> | >And there have certainly been other machines which didn't use single
|> | >linear stacks, e.g., early IBM S/360 code which statically allocated
|> | >register save blocks in the callers, which the callees dynamically
|> | >linked and unlinked (with back-pointers) without moving or "growing"
|> | >anything. The call stack was this a singly-linked list of static blocks
|> | >randomly scattered all over memory. [Yes, this did *not* support
|> | >recursive routines! At least, not this default linkage.]
|> |
|> | Sorry, Rob, but that is completely wrong. Yes, it allowed recursive
|> | routines, in at least three separate ways, all of which were used.
|> | There was no requirement for the save areas to be static.
|> +---------------
|>
|> Sorry, I guess I misspoke. I didn't mean to imply that there was any
|> *requirement* for the save areas to be static, only that it was permitted
|> (if recursion wasn't needed). And for some programmers (at least, around
|> the shops where I was first exposed to S/360 code) it was their default
|> coding style, and that if you did that the resulting stack was therefore
|> non-linear (discontinuous).

It is PERMITTED under Unix on RISC systems, too, and some compilers
for some languages have done it!

But, yes, 'stacks' could be discontiguous, and often were. That also
applied to quite a few languages that allowed recursion. The same
would be true on any Unix/RISC compiler that used similar techniques.


Regards,
Nick Maclaren.