Re: linux-specific behavior, or coincidence?

Sir Jackery wrote:
On Thu, 15 Mar 2007, The Natural Philosopher wrote:

Sir Jackery wrote:
On Thu, 15 Mar 2007, The Natural Philosopher wrote:

Amadeus W.M. wrote:
What happens if you put another function call between "x = foobar();"
and "y=x[0]". I suspect you're just seeing the fact that the stack
hasn't been reused yet. Try putting a 'printf("hello there\n");' in
there.


Of course, calling something else between x=foobar() and y=*x forces the stack to be reused. Is there any circumstance when the stack is overwritten even if I don't force it with another function call? For instance (however unlikely), could the system choose to run another process in between the two instructions? What happens then with the stack? It's not going to stay the same, is it?

An asynchronous interrupt MIGHT cause the stack to get trashed..
synchronous interrupt.


Asynchronous.

Strictly synchronous interrupts aren't interrupts at all.


How can you say that? Synchronous interrupts (deterministic) are functions of memory state like program overflow. Asynchronous interrupts (nondeterministic) are external device or hardware related interrupts. It is highly unlikely that a nondeterministic interrupt would corrupt the stack, but deterministic ones possible could.

Ah..thats becase I am an hardware guy,..

the normal mechanism for an asynchronous interrupt is that the processor will *at the least push* the program counter into the current stack, and jump to the interrupt service routine.

I haver seen SOME hardware designs where the program counter is stored in a separate interrupt stack, but its not that common.

For re-entrancy, the ISR itself will normally also push any registers it needs to use into the stack..so you tend to use ate least 4-5 stack locations in the current stack under an asynchronous interrupt from e.g. an IO or timer interrupt.

'Intrerrupts' that are triggered by the code thread itself are not what I call interrupts at all really, they are just a different sort of subroutine call.

And they wont happen in general between two lines of C code. Its normally something that is built into the kernel. The possible exception being a call to memory that is illegal..resulting in a trap type instruction.

However the code shown by the OP is not exactly accessing illegal memory in that sense. Few processors check for access to the stack below the current stack pointer rather than above.

The code fragment presented is a use of memory whose location is not illegal, but whose content is highly implementation specific and potentially transitory, that's all.

If his original declaration was for a character array that was - say - a megabyte deep instead of a few characters, then x[0] might well be deeper than almost anything would carry the stack pointer, and he would stand a good chance of better persistence of the data.

Or he might instantly overflow the stack area with such a declaration :-)









--
Sir Jackery
.

Relevant Pages

  • Re: VxWorks Interrupts
    ... Where could find the memory map when VxWorks is running or booting... ... Some of this gets changed for cpu's that don't have interrupt stacks, ... and gets permuted for cpu's where the stack grows upwards toward higher ...
    (comp.os.vxworks)
  • Re: Interrupt context...
    ... > gone through most of the posts on interrupt in usenet. ... > kernel stack and ISR is executed. ... More may be saved depending on the architecture. ... Here the kernel have assembler code to save all general ...
    (comp.os.linux.development.system)
  • Re: BTX on USB pen drive
    ... my pc but doesn't boot on my supermicro server. ... * Emulate MOV reg,CRx. ... * Protected Mode Hardware interrupt jump table. ... * We place a trampoline on the user stack that will return to rret_tramp ...
    (freebsd-stable)
  • Re: interrupt routine and application pages
    ... application stack in the interrupt context. ... are still in the context of interrupted thread. ... your code runs at raised IRQL, Memory Manager just had no chance to ...
    (microsoft.public.development.device.drivers)
  • [PATCH 4/6] UML - IRQ stacks
    ... Add a separate IRQ stack. ... interrupt run on a separate stack rather than starting on the normal ... The IRQ stack for CPU 0 is declared in the same way as the initial ... handler can't run because it has no idea what shape the stack is in. ...
    (Linux-Kernel)