From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26377 invoked by alias); 5 Feb 2004 01:22:34 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 26359 invoked from network); 5 Feb 2004 01:22:33 -0000 Received: from unknown (HELO touchme.toronto.redhat.com) (216.129.200.20) by sources.redhat.com with SMTP; 5 Feb 2004 01:22:33 -0000 Received: from redhat.com (toocool.toronto.redhat.com [172.16.14.72]) by touchme.toronto.redhat.com (Postfix) with ESMTP id EEF05800195; Wed, 4 Feb 2004 20:22:32 -0500 (EST) Message-ID: <40219AD8.70605@redhat.com> Date: Thu, 05 Feb 2004 01:22:00 -0000 From: Jeff Johnston User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 MIME-Version: 1.0 To: Jeff Johnston Cc: Daniel Jacobowitz , David Carlton , gdb Subject: [PATCH]: Re: gdb.base/pending.exp failures References: <20040205002140.GA29659@nevyn.them.org> <4021965F.2010902@redhat.com> In-Reply-To: <4021965F.2010902@redhat.com> Content-Type: multipart/mixed; boundary="------------060606030702030305010700" X-SW-Source: 2004-02/txt/msg00038.txt.bz2 This is a multi-part message in MIME format. --------------060606030702030305010700 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-length: 1492 I have just checked in the accompanying patch which takes Daniel's suggestion of indirectly calling pendfunc1 from the main program. I have tested it on both ia64-linux and i686-linux. -- Jeff J. 2004-02-04 Jeff Johnston * gdb.base/pendshr.c (pendfunc): New function that calls pendfunc1. * gdb.base/pending.c: Call pendfunc instead of pendfunc1. Jeff Johnston wrote: > Daniel Jacobowitz wrote: > >> Just a note of probable-cause: Jeff, on which platforms did you test >> this testcase? I bet it wasn't i386-linux. >> >> > > You're right. I tested ia64, not i386. > >> On Wed, Feb 04, 2004 at 04:01:21PM -0800, David Carlton wrote: >> >> >>> (gdb) break pendfunc1 >>> >>> Breakpoint 1 at 0x804839c >>> >>> (gdb) FAIL: gdb.base/pending.exp: set pending breakpoint >>> >> >> >> This function is in a shared library that hasn't been loaded yet. >> However, on i386-linux (and many other platforms), the call will go >> through a PLT entry, and the entry in the application's symbol table >> will appear as an SHN_UNDEF symbol with a non-zero address pointing at >> the PLT entry. GDB will re-resolve the breakpoint after shared >> libraries have been loaded. This is already-existing functionality. >> >> If you don't want to use dlopen in the test, try setting breakpoints on >> a function not called directly from the executable (i.e. called from >> within the library). >> >> >> > Thanks for the explanation. > > --------------060606030702030305010700 Content-Type: text/plain; name="pendfix.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="pendfix.patch" Content-length: 1000 Index: pending.c =================================================================== RCS file: /cvs/src/src/gdb/testsuite/gdb.base/pending.c,v retrieving revision 1.1 diff -u -p -r1.1 pending.c --- pending.c 2 Feb 2004 21:14:33 -0000 1.1 +++ pending.c 5 Feb 2004 01:17:48 -0000 @@ -23,13 +23,13 @@ int k = 0; -extern void pendfunc1 (int x); +extern void pendfunc (int x); int main() { - pendfunc1 (3); /* break main here */ - pendfunc1 (4); + pendfunc (3); /* break main here */ + pendfunc (4); k = 1; - pendfunc1 (3); + pendfunc (3); return 0; } Index: pendshr.c =================================================================== RCS file: /cvs/src/src/gdb/testsuite/gdb.base/pendshr.c,v retrieving revision 1.1 diff -u -p -r1.1 pendshr.c --- pendshr.c 2 Feb 2004 21:14:33 -0000 1.1 +++ pendshr.c 5 Feb 2004 01:17:48 -0000 @@ -26,3 +26,8 @@ void pendfunc1 (int x) int y = x + 4; printf ("in pendfunc1, x is %d\n", x); } + +void pendfunc (int x) +{ + pendfunc1 (x); +} --------------060606030702030305010700--