This is the mail archive of the gdb-prs@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: breakpoints/1407: Gdb with gcc on Solaris crashes with segmentationfault when using "call"


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
 
 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]