This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] canonical linespec and multiple breakpoints ...
- From: Tom Tromey <tromey at redhat dot com>
- To: Pedro Alves <pedro at codesourcery dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Fri, 18 Nov 2011 12:31:07 -0700
- Subject: Re: [RFC] canonical linespec and multiple breakpoints ...
- References: <20110505162855.GA2546@adacore.com> <201108021633.04777.pedro@codesourcery.com> <m3oc073fmp.fsf@fleche.redhat.com> <201108021900.13298.pedro@codesourcery.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