Re: remote/1187: 'call' attempts additional remote 's'tep

[Daniel Jacobowitz <drow at mvista dot com>]

The following reply was made to PR remote/1187; it has been noted by GNATS.

From: Daniel Jacobowitz <drow at mvista dot com>
To: baccala at freesoft dot org
Cc: gdb-gnats at sources dot redhat dot com
Subject: Re: remote/1187: 'call' attempts additional remote 's'tep
Date: Thu, 24 Apr 2003 14:41:13 -0400

 On Thu, Apr 24, 2003 at 12:37:35AM -0000, baccala at freesoft dot org wrote:
 > 
 > >Number:         1187
 > >Category:       remote
 > >Synopsis:       'call' attempts additional remote 's'tep
 > >Confidential:   no
 > >Severity:       non-critical
 > >Priority:       low
 > >Responsible:    unassigned
 > >State:          open
 > >Class:          sw-bug
 > >Submitter-Id:   net
 > >Arrival-Date:   Thu Apr 24 00:38:00 UTC 2003
 > >Closed-Date:
 > >Last-Modified:
 > >Originator:     baccala at freesoft dot org
 > >Release:        gdb-5.2.1 gdb-5.3
 > >Organization:
 > >Environment:
 > i386 Linux host / powerpc remote stub
 > >Description:
 > after building either gdb-5.2.1 or gdb-5.3 for an Intel
 > host and powerpc target, then connecting to a remote
 > powerpc Linux kernel via serial stub, 'call' command
 > fails.  After creating a dummy stack frame, calling it,
 > returning, and getting the breakpoint, debugger attempts
 > to continue to program from that point (end of dummy)
 > resulting in various bizarre malfunctions
 > >How-To-Repeat:
 > compile gdb 5.2.1 or gdb 5.3 for intel host, powerpc target
 > connect to remote powerpc stub (linux-2.4.20 has a bug in
 > powerpc stub handling, requiring attached patch before it
 > works) then attempt 'call' command (with remote debugging on)
 
 You didn't attach the patch, but I assume it's the missing ampersand?
 
 In general, Linux kernel stubs have required some special code for
 function calls to work; dealing with the fact that KGDB runs on the
 main kernel stack.  This work hasn't been done for PowerPC, so I think
 that's more likely to be the real problem.  Most likely the stack has
 gotten corrupted somehow.
 
 I checked with our KGDB gurus here, and they didn't expect function
 calls to work on PPC32.
 
 > patch infrun.c at line 2563 (gdb-5.2) adding following code:
 >    if (stop_stack_dummy) { stop_stepping(ecs);  return; }
 > code probably should not reach this point during a stack
 > dummy call, but does
 > >Release-Note:
 > >Audit-Trail:
 > >Unformatted:
 > 
 
 -- 
 Daniel Jacobowitz
 MontaVista Software                         Debian GNU/Linux Developer