From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-11690-listarch-gdb-patches=sourceware.cygnus.com@sources.redhat.com>
Received: (qmail 4673 invoked by alias); 8 Jan 2002 17:00:17 -0000
Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-patches-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sources.redhat.com>
List-Help: <mailto:gdb-patches-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: gdb-patches-owner@sources.redhat.com
Received: (qmail 4537 invoked from network); 8 Jan 2002 17:00:04 -0000
Received: from unknown (HELO fred.ninemoons.com) (64.232.230.104)
  by sources.redhat.com with SMTP; 8 Jan 2002 17:00:04 -0000
Received: (from fnf@localhost)
	by fred.ninemoons.com (8.11.6/8.11.6) id g08Gwae25774;
	Tue, 8 Jan 2002 09:58:36 -0700
From: Fred Fish <fnf@fred.ninemoons.com>
Message-Id: <200201081658.g08Gwae25774@fred.ninemoons.com>
Subject: [RFA] Accept compiler internal use of memcpy/bcopy for structs
To: gdb-patches@sources.redhat.com
Date: Tue, 08 Jan 2002 09:00:00 -0000
Cc: fnf@redhat.com
Reply-To: fnf@redhat.com
X-Mailer: ELM [version 2.5 PL6]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-SW-Source: 2002-01/txt/msg00135.txt.bz2

For cases where the compiler uses memcpy/bcopy to copy structs around,
and those calls are found in a library for which debugging line number
information is available, attempting to step into a function where a
large struct is passed by value will first stop at the memcpy/bcopy
call that the compiler calls prior to the user function.

The comment in step-test.exp says that "opinion is bitterly divided
about whether this is the right behavior for GDB or not".  Regardless
of which opinion you have, you would probably have to agree that gdb
is currently behaving as designed, in the absence of additional
code to not stop in functions used internally by the compiler.  Thus
I believe the correct behavior of the test suite is to accept the
cases where gdb stops in memcpy/bcopy.

Here is a patch to fix the testsuite.

-Fred



2002-01-08  Fred Fish  <fnf@redhat.com>

	* gdb.base/step-test.exp: Accept stopping in memcpy/bcopy when we
	have debugging info for those functions and the compiler uses them
	internally to copy structs around.

Index: gdb.base/step-test.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/step-test.exp,v
retrieving revision 1.3
diff -c -p -r1.3 step-test.exp
*** step-test.exp	2001/03/06 08:21:51	1.3
--- step-test.exp	2002/01/08 16:51:30
*************** gdb_test \
*** 212,220 ****
  gdb_test "continue" \
           ".*Breakpoint ${decimal},.*large_struct_by_value.*" \
  	 "run to pass large struct"
! gdb_test "step" \
!          ".*step-test.exp: arrive here 1.*" \
!          "large struct by value"
  
  gdb_continue_to_end "step-test.exp"
  
--- 212,244 ----
  gdb_test "continue" \
           ".*Breakpoint ${decimal},.*large_struct_by_value.*" \
  	 "run to pass large struct"
! send_gdb "step\n"
! gdb_expect {
!     -re ".*step-test.exp: arrive here 1.*$gdb_prompt $" {
! 	pass "large struct by value"
!     }
!     -re ".*(memcpy|bcopy).*$gdb_prompt $" {
! 	send_gdb "finish\n" ; gdb_expect -re "$gdb_prompt $"
! 	send_gdb "step\n"
! 	gdb_expect {
! 	    -re ".*step-test.exp: arrive here 1.*$gdb_prompt $" {
! 		pass "large struct by value"
! 	    }
! 	    -re ".*$gdb_prompt $" {
! 		fail "large struct by value"
! 	    }
! 	    timeout {
! 		fail "large struct by value (timeout)"
! 	    }
! 	}
!     }
!     -re ".*$gdb_prompt $" {
! 	fail "large struct by value"
!     }
!     timeout {
! 	fail "large struct by value (timeout)"
!     }
! }
  
  gdb_continue_to_end "step-test.exp"