Re: Breakpoint duplication over new inferiors

Pedro Alves
2011-05-03T10:22:19Z

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