This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: don't set the pspace on ordinary breakpoints


>>>>> "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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]