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

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

[Mike Stump]

> 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'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.

> 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.

Hope this helps.

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

[George T. Talbot]

Geoff Keating wrote:
> 
> "George T. Talbot" <george@phat.com> writes:
> 
> > <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>
> 
> The program 'catchsegv' which comes with GNU libc 2.1 and later does
> exactly this.

Thanks for the tip.  I gave it a try, and it hangs, rather than giving
me a segfault, with Xosview showing 100% cpu taken up by SYS rather than
USER.

Oh well.  I'll keep hunting.

Thanks for trying to help, though.  I really do appreciate it.

--
George T. Talbot
george at moberg dot com

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

[Geoff Keating]

"George T. Talbot" <george@phat.com> writes:

> <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>

The program 'catchsegv' which comes with GNU libc 2.1 and later does
exactly this.

-- 
- Geoffrey Keating <geoffk@cygnus.com>

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

[George T. Talbot]

>> 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

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

[George T. Talbot]

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?

I'm specifically interested in two things:

1)  How does -fstack-check determine whether the stack has been overrun?
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?

I'm using gcc 2.95.2 on Mandrake Linux 7.0 (glibc 2.1.2, I believe).

Thanks.

--
George T. Talbot
george at moberg dot com