From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4219 invoked by alias); 3 May 2011 13:20:41 -0000 Received: (qmail 4209 invoked by uid 22791); 3 May 2011 13:20:40 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST X-Spam-Check-By: sourceware.org Received: from mail-vw0-f41.google.com (HELO mail-vw0-f41.google.com) (209.85.212.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 03 May 2011 13:20:23 +0000 Received: by vws4 with SMTP id 4so63517vws.0 for ; Tue, 03 May 2011 06:20:22 -0700 (PDT) Received: by 10.220.98.79 with SMTP id p15mr2797858vcn.23.1304428822127; Tue, 03 May 2011 06:20:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.61.6 with HTTP; Tue, 3 May 2011 06:20:02 -0700 (PDT) In-Reply-To: <201105031122.08202.pedro@codesourcery.com> References: <201105031122.08202.pedro@codesourcery.com> From: Kevin Pouget Date: Tue, 03 May 2011 13:20:00 -0000 Message-ID: Subject: Re: Breakpoint duplication over new inferiors To: Pedro Alves Cc: gdb@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: 2011-05/txt/msg00016.txt.bz2 On Tue, May 3, 2011 at 6:22 AM, Pedro Alves wrote: > On Tuesday 03 May 2011 10:30:28, Kevin Pouget wrote: >> Hello, >> >> I'd like to understand how breakpoints are supposed to be duplicated >> when a new inferior is started/attached (in my cases)/forked. >> >> Namely, with a code like: >> > >> > 1 =A0 =A0int main() { >> > 2 =A0 =A0 =A0 =A0if (fork()) { >> > 3 =A0 =A0 =A0 =A0 =A0 =A0send (0,0,0); >> > 4 =A0 =A0 =A0 =A0} else { >> > 5 =A0 =A0 =A0 =A0 =A0 =A0recv(0,0,0) ; >> > 6 =A0 =A0 =A0 =A0} >> > 7 =A0 =A0} >> >> and >> > >> > (gdb) b main >> > Breakpoint 1 at 0x400558: file fork.c, line 2. >> > (gdb) b send >> > Breakpoint 2 at 0x400448 >> > (gdb) set detach-on-fork off >> > (gdb) run >> > ... >> > (gdb) info breakpoint >> > Num =A0 =A0 Type =A0 =A0 =A0 =A0 =A0 Disp Enb Address =A0 =A0 =A0 =A0 = =A0 =A0What >> > 1 =A0 =A0 =A0 breakpoint =A0 =A0 keep y =A0 >> > =A0 =A0 breakpoint already hit 1 time >> > 1.1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 y =A0 =A0 0x000000= 0000400558 in main at fork.c:2 inf 2 >> > 1.2 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 y =A0 =A0 0x000000= 0000400558 in main at fork.c:2 inf 1 >> > 2 =A0 =A0 =A0 breakpoint =A0 =A0 keep y =A0 0x0000003cbd0e1a60 = inf 1 >> >> it seems that `libc' breakpoints are not correctly duplicated. >> According to my investigation, the difference occurs in >> > breakpoint.c:addr_string_to_sals -- sals =3D decode_line_1 (&s, 1, (st= ruct symtab *) NULL, 0, NULL); >> >> which doesn't return two locations, but only one ... >> is it a bug? any idea what to do to solve it? > > This is currently done by expand_line_sal_maybe -> expand_line_sal, not > by decode_line_1 returning multiple sals. just a few lines away from what I guessed! > Looks like it isn't working on breakpoints set on symbols for which > there is no debug info. (the matching is currently done by file/lineno > currently, IIRC, for lack of better mechanism). I'll need to set and handle (in Python) internal BPs at the same location (namely a function) on multiple inferiors. One way would be to simple create as many BPs as inferiors, but it would certainly be unproductive, and opposite to the idea of multiprocess ... Otherwise, it might be convenient, for me at least, to be able to set in Python "aliases" location to a BP: myBP.addLocation(...) , myBP.getLocations() (there is currently no way to get the memory location of a BP, according to the documentation) A third possiblity, which was probably refute when "expand_line_sal_maybe" codes where implemented, (but which would make sense to me) would be to reset the breakpoint location according to their string_addr And BP location should be removable as well: >> > 1.1 y 0x0000000000400558 in main at fork.c= :2 inf 2 >> > 1.2 y 0x0000000000400558 in main at fork.c= :2 inf 1 (gdb) delete 1.1 warning: bad breakpoint number at or near '1.1' let me know what you think about it, to know if I should spend some time on the issue thanks, Kevin