From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1396 invoked by alias); 14 Oct 2008 13:24:49 -0000 Received: (qmail 1378 invoked by uid 22791); 14 Oct 2008 13:24:45 -0000 X-Spam-Check-By: sourceware.org Received: from eu1sys200aog012.obsmtp.com (HELO eu1sys200aog012.obsmtp.com) (207.126.144.126) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 14 Oct 2008 13:23:57 +0000 Received: from source ([164.129.1.35]) (using TLSv1) by eu1sys200aob012.postini.com ([207.126.147.11]) with SMTP; Tue, 14 Oct 2008 13:23:54 UTC Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 1284BDB01 for ; Tue, 14 Oct 2008 13:23:54 +0000 (GMT) Received: from mail1.bri.st.com (unknown [164.129.8.218]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id A3EC84C34B for ; Tue, 14 Oct 2008 13:23:53 +0000 (GMT) Received: from [164.129.14.85] (bri1017.bri.st.com [164.129.14.85]) by mail1.bri.st.com (MOS 3.8.7a) with ESMTP id CKQ28419 (AUTH antony); Tue, 14 Oct 2008 14:23:53 +0100 (BST) Message-ID: <48F49D68.2030701@st.com> Date: Tue, 14 Oct 2008 13:24:00 -0000 From: Antony KING User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: gdb@sourceware.org Subject: Strange effect in GDB 6.8 when setting breakpoint on symbol with both strong and weak definitions Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-10/txt/msg00058.txt.bz2 Consider the following source files a.c and b.c: == a.c == #include void f(void) __attribute__((weak)); void f(void) { printf("FAIL\n"); } int main(void) { f(); return 0; } == a.c == == b.c == #include void f(void) { printf("PASS\n"); } == b.c == If I compile them (on RHEL3 but I don't think this is significant) using "gcc -g a.c b.c" and then debug the resulting executable using the following GDB script: file a.out set trace-commands 1 break f tbreak main info breakpoints run info breakpoints break f continue I see the following output from GDB: > +break f > Breakpoint 1 at 0x8048382: file b.c, line 5. > +tbreak main > Breakpoint 2 at 0x8048369: file a.c, line 11. > +info breakpoints > Num Type Disp Enb Address What > 1 breakpoint keep y 0x08048382 in f at b.c:5 > 2 breakpoint del y 0x08048369 in main at a.c:11 > +run > main () at a.c:11 > 11 f(); > +info breakpoints > Num Type Disp Enb Address What > 1 breakpoint keep y 0x0804834a in f at a.c:5 > +break f > Breakpoint 3 at 0x804834a: file a.c, line 6. > +info breakpoints > Num Type Disp Enb Address What > 1 breakpoint keep y 0x0804834a in f at a.c:5 > 3 breakpoint keep y 0x0804834a in f at a.c:6 > +continue > PASS > > Program exited normally. As you can see the location of the breakpoint at f() has been shifted from its definition in b.c (which is what I expected) before the program is run, to its definition in a.c after the program stopped in main() (which is not what I would expect). This shift of location seems wrong to me and quite unexpected. Is this a bug ? Another problem is that although there are 2 definitions of f() in the program, only 1 breakpoint is being set. My understanding is that GDB should set multiple breakpoints on f(). Is this correct (or is this only a feature that is enabled when debugging C++ applications) ? [The application I am trying to debug is more complicated embedded application running on an SH-4 CPU but the example above illustrates the problems I am encountering.] Thanks for any illumination. Cheers, Antony.