Re: [RFC] canonical linespec and multiple breakpoints ...

[Tom Tromey <tromey@redhat.com>]

>>>>> "Pedro" == Pedro Alves <pedro@codesourcery.com> writes:

Finally replying to this old note.

The context for this note is this patch, which has not been checked in:

    http://sourceware.org/ml/gdb-patches/2011-03/msg00606.html

Pedro> I never replied to your patch, but my reaction was that it is
Pedro> probably breaking breakpoints in the new inferiors today, even
Pedro> without any linespec/multi breakpoints work.

Tom> Is there a way to set a breakpoint in a new inferior without first
Tom> loading the debuginfo by hand?  It has been a while since I was looking
Tom> at this, but I don't remember finding a way.

Tom> If there is one, though, I can easily test this.

Pedro> If you set a breakpoint before the fork, the
Pedro> breakpoint will end up with locations in the new inferior
Pedro> after the fork.  Same if e.g., you set a breakpoint before
Pedro> a fork/exec, and post-exec image happens to have
Pedro> been compiled from the same code (file:lineno) as the 
Pedro> original breakpoint's location was resolved to.  I was
Pedro> under the impression your patch would make it so 
Pedro> the new inferior would no longer stop for these breakpoints.

I finally tried this today by making a simple program that forks,
applying the patch to git master, enabling multi-inferior, and
debugging.  It works fine:

    (gdb) c
    Continuing.
    hi bob from 16888
    [New process 16889]

    Breakpoint 2, doit () at ft.c:6
    6	  printf ("hi bob from %d\n", (int) getpid());

I think this is what I would expect, anyway.  The patch in question
changes gdb to lazily read debuginfo for inferiors that arise from
forks.  But, in this scenario, breakpoint re-setting causes gdb to need
the debuginfo, so it is read at that point -- on demand.

I plan to check in this patch after 7.4 branches.

Tom