From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6940 invoked by alias); 16 Jan 2003 18:45:35 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 6926 invoked from network); 16 Jan 2003 18:45:27 -0000 Received: from unknown (HELO duracef.shout.net) (204.253.184.12) by sources.redhat.com with SMTP; 16 Jan 2003 18:45:27 -0000 Received: (from mec@localhost) by duracef.shout.net (8.11.6/8.11.6) id h0GIjL916857; Thu, 16 Jan 2003 12:45:21 -0600 Date: Thu, 16 Jan 2003 18:45:00 -0000 From: Michael Elizabeth Chastain Message-Id: <200301161845.h0GIjL916857@duracef.shout.net> To: ezannoni@redhat.com Subject: Re: [PATCH] Make tests more flexible Cc: carlton@math.stanford.edu, gdb-patches@sources.redhat.com X-SW-Source: 2003-01/txt/msg00621.txt.bz2 Elena Z asks: > So, recapping, which one is correct? the old compiler (and the test is > right) or the new compiler (and the test is wrong)? Argh, my previous answer was crap. But now I understand. It will be easy to fix, too. Here is the source code for advance.c: int main () { int result; int b, c; c = 5; b = 3; /* advance this location */ func (c); /* stop here after leaving current frame */ func3 (); /* break here */ result = bar (b + foo (c)); return 0; /* advance malformed */ } Here is some generated assembly code with gcc 2.95.3: 0x8048462 : push %eax 0x8048463 : call 0x8048408 0x8048468 : add $0x10,%esp 0x804846b : call 0x8048434 Here is some generated assembly code with gcc 3.2.1: 0x80483d3 : mov %eax,(%esp,1) 0x80483d6 : call 0x8048380 0x80483db : call 0x80483a3 After the call to 'func', gcc v2 emits an instruction to clean up the arguments on the stack ('add $0x10,%esp'). gcc v3 does lazy stack cleanup, it lets stuff stay on the stack for a while and cleans it up later, saving some instructions. Here is a log excerpt with gcc 2.95.3: # target=native, host=i686-pc-linux-gnu, osversion=red-hat-8.0, # gdb=HEAD%20030115, gcc=2.95.3, binutils=2.13.2.1, libc=vendor, # gformat=dwarf-2 advance func3^M 0x08048468 in main () at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/testsuite/gdb.base/advance.c:40^M 40 func (c); /* stop here after leaving current frame */^M (gdb) PASS: gdb.base/advance.exp: advance function not called by current frame gdb hits the return breakpoint, which is on the 'add $0x10,%esp' instruction, still in the middle of line 40. And here is a log excerpt from gcc 3.2.1: # target=native, host=i686-pc-linux-gnu, osversion=red-hat-8.0, # gdb=HEAD%20030115, gcc=3.2.1, binutils=2.13.2.1, libc=vendor, # gformat=dwarf-2 advance func3^M main () at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/testsuite/gdb.base/advance.c:41^M 41 func3 (); /* break here */^M (gdb) FAIL: gdb.base/advance.exp: advance function not called by current frame gdb hits the return breakpoint, which is the first instruction of line 41. So gdb is doing the right thing, but the test script is too strict. gdb might stop on either line 40 or line 41, depending on how the function call in line 40 gets compiled: whether the 'call' instruction is the last machine instruction for line 40 or not. In general we can't say anything about whether the 'call' instruction will be the last machine instruction for a C function call, so we can't predict whether the return breakpoint will be an instruction in line 40 or the first instruction of line 41. The test script has to acommodate both forms. Michael C