Re: -fstack-check on Linux x86--Dumb question...

["George T. Talbot" <george at phat dot com>]

>> Date: Fri, 17 Mar 2000 20:14:21 -0500
>> From: "George T. Talbot" <george@moberg.com>
>
>> I've got a program which fails with a SIGSEGV when -fstack-check is
>> turned on.  Would anyone have more information about how
>> -fstack-check works on an Intel processor under Linux?
>
>Sure, it works by probing the stack before using it, to ensure that
>the stack is really there.  If it isn't, the compiler expects the page
>to not be mapped and for the operation to fault.  The amount of stack
>space is set for the main thread by the limit or ulimit command, see
>you shell's documentation.  If you are running out, just up the amount
>allocated, and/or add more swap.
>
>If you're not using threads, there is almost no point in using this
>flag.  Why do you bother with this flag?


I am using threads, although the failure I see happens in my test program
which tests a bunch of low-level objects before it starts any threads.  It
fails in the test of one of the low-level objects.

>> I'm specifically interested in two things:
>
>> 1)  How does -fstack-check determine whether the stack has been overrun?
>
>It doesn't.  It just does an access to fault the program, should you
>overrun it.  The OS determines that you overran the stack by not
>mapping the page just past the stack.  This compiler flag arranges to
>access all stack pages in growth order without skipping pages.


Aaaahhhhh....mucho enlightenment.

>> 2)  Is there a way using GDB, or some other tool of which I'm not aware,
>>     to find the specific instruction and access address of the SIGSEGV?
>
>Yes, the command is run.  You can't be using it, without having tried
>this command already.  By default, gdb will stop on the instruction
>that faulted (or just after it, I forget which).  `x/20i $pc' will
>show you the instructions, if you wish to see them.  `where' will
>similar information.


I was able to disassemble my program and look at the instructions where it
faulted.  I was hoping to find the actual faulted address--the specific
access address that caused the fault, not the program counter.  Sometimes I
find x86 assembly to be rather confusing.

<whine>
It would be a nice patch to GDB and/or GNU/Linux to print:

    "Program received SIGSEGV at address 0x2394782 while attempting
    to read from address 0xFDFEFFF."

Right now, it just gives me the program counter.  Of course, I'm not really
sure of how to patch GDB or the kernel to give me such support.
</whine>

Thanks for your help, this was most enlightening.

-George