Breakpoint duplication over new inferiors

Breakpoint duplication over new inferiors

[Kevin Pouget]

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?


cordially,

Kevin

Re: Breakpoint duplication over new inferiors

[Pedro Alves]

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

Re: Breakpoint duplication over new inferiors

[Kevin Pouget]

On Tue, May 3, 2011 at 6:22 AM, Pedro Alves <pedro@codesourcery.com> 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    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.

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