[RFC] canonical linespec and multiple breakpoints ...
Tom Tromey
tromey@redhat.com
Fri Nov 18 19:31:00 GMT 2011
>>>>> "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
More information about the Gdb-patches
mailing list