This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
Re: breakpoints/1407: Gdb with gcc on Solaris crashes with segmentationfault when using "call"
- From: Andrew Cagney <ac131313 at redhat dot com>
- To: kettenis at gnu dot org
- Cc: gdb-prs at sources dot redhat dot com,
- Date: 11 Oct 2003 16:18:00 -0000
- Subject: Re: breakpoints/1407: Gdb with gcc on Solaris crashes with segmentationfault when using "call"
- Reply-to: Andrew Cagney <ac131313 at redhat dot com>
The following reply was made to PR breakpoints/1407; it has been noted by GNATS.
From: Andrew Cagney <ac131313@redhat.com>
To: gdb-gnats@sources.redhat.com
Cc:
Subject: Re: breakpoints/1407: Gdb with gcc on Solaris crashes with segmentation
fault when using "call"
Date: Sat, 11 Oct 2003 12:08:55 -0400
> Works fine here (Solaris 2.6, gcc 3.3.2). Wait a moment...
>
> ...does your Solaris system have a non-executable stack? If I set:
>
> $ tail /etc/system
> *
> * To set variables in 'unix':
> *
> * set nautopush=32
> * set maxusers=40
> *
> * To set a variable named 'debug' in the module named 'test_module'
> *
> * set test_module:debug = 0x13
> set noexec_user_stack = 1
>
> I see the same segfaults as you're seeing. Right now calling
> functions from GDB requires the execution of a bit of code on the
> stack. We have some ideas to fix this, but it's not a simple problem
> to fix.
>
> For now the only thing I can advice you is to make the stack
> executable, or find another machine that doesn't have a non-executable
> stack.
Looking at the branch, it appears to be using ON_STACK, push_dummy_call,
and push_dummy_code? That would mean that the hard bits are done.
Looking at the output from the testcase, GDB even appears to know that
it's at the dummy frame breakpoint (the <function called from gdb> message).
All that's missing is mods to "infrun.c" that let GDB interpret SEGV as
a breakpoint trap (not unreasonable if GDB's to get breakpoints using
memory mapping working). Hmm, looking at the code:
/* NOTE: cagney/2003-03-29: These two checks for a random signal
at one stage in the past included checks for an inferior
function call's call dummy's return breakpoint. The original
comment, that went with the test, read:
``End of a stack dummy. Some systems (e.g. Sony news) give
another signal besides SIGTRAP, so check here as well as
above.''
If someone ever tries to get get call dummys on a
non-executable stack to work (where the target would stop
with something like a SIGSEG), then those tests might need to
be re-instated. Given, however, that the tests were only
enabled when momentary breakpoints were not being used, I
suspect that it won't be the case. */
if (stop_signal == TARGET_SIGNAL_TRAP)
...
Try changing it to:
if (stop_signal == .._TRAP || _SEGV)
Andrew