This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: RFC: don't set the pspace on ordinary breakpoints
- From: Tom Tromey <tromey at redhat dot com>
- To: Pedro Alves <pedro at codesourcery dot com>
- Cc: gdb-patches at sourceware dot org, Ulrich Weigand <uweigand at de dot ibm dot com>
- Date: Wed, 02 Nov 2011 13:46:54 -0600
- Subject: Re: RFC: don't set the pspace on ordinary breakpoints
- References: <m3lis6h35l.fsf@fleche.redhat.com> <201111021854.42981.pedro@codesourcery.com>
>>>>> "Pedro" == Pedro Alves <pedro@codesourcery.com> writes:
Pedro> Could have been two independent patches.
Ok, noted.
Tom> First, it changes ordinary breakpoints to set leave their 'pspace' field
Tom> NULL. The rationale for this is that, with the ambiguous linespec
Tom> patch, a linespec may apply to different program spaces, not just the
Tom> one which was selected when the breakpoint was created. For these
Tom> breakpoints, we do not want breakpoint_program_space_exit to remove the
Tom> breakpoint.
Pedro> I'm not clear how this isn't breaking multi-process without
Pedro> the linespec changes. I mean, if we no longer have a pspace
Pedro> pointer, breakpoint re-setting will no longer work correctly.
Pedro> (breakpoint_re_set -> ... -> prepare_re_set_context)
Yeah, it probably does.
I'm not sure why this doesn't result in any regressions.
I won't put it in separately... it is mostly useful as a way to break
off a chunk of the huge linespec patch for readability.
Pedro> I don't think that's correct. During startup, we disable user
Pedro> breakpoints, because the symbols haven't been relocated yet.
Pedro> But, we still need to insert internal breakpoints set at magic
Pedro> addresses (not through symbols), so that we know when the startup
Pedro> is done with. Ulrich?
Ok. How would I test this?
Plan B would be to put the startup-disabled state on bp_location.
Tom