Re: Breakpoint duplication over new inferiors

[Pedro Alves <pedro@codesourcery.com>]

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    int main() {
> > 2        if (fork()) {
> > 3            send (0,0,0);
> > 4        } else {
> > 5            recv(0,0,0) ;
> > 6        }
> > 7    }
> 
> 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     Type           Disp Enb Address            What
> > 1       breakpoint     keep y   <MULTIPLE>
> >     breakpoint already hit 1 time
> > 1.1                         y     0x0000000000400558 in main at fork.c:2 inf 2
> > 1.2                         y     0x0000000000400558 in main at fork.c:2 inf 1
> > 2       breakpoint     keep y   0x0000003cbd0e1a60 <send> 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 = decode_line_1 (&s, 1, (struct 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.
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).

-- 
Pedro Alves