Re: [rfc] Infrastructure to disable breakpoints during inferior startup

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

Tom Tromey wrote:

> Ulrich> (In any case, moving this variable over to a struct inferior field
> Ulrich> can be trivially done after Pedro's patches are merged; I'm not sure
> Ulrich> we have to wait because of that ...)
> 
> I'm inclined to agree as a general rule that we shouldn't put too much
> work into helping out uncommitted patches.  In this case, though, we do
> already have struct inferior, and I wonder if the seemingly steady
> stream of needed fixes is making Pedro's to-do list impossible.
> I suppose if he doesn't speak up then I won't object any more :-)

Thinking about it a bit more, it seems that in the context of Pedro's
patches, this flag really needs to be a symbol-space property, not an
inferior property: it basically says that objfiles in this symbol
space have not yet been relocated to their final addresses and therefore
cannot be used to determine breakpoint addresses.

In the situation where multiple inferiors potentially share a symbol
space, this property applies to all of them.  Also, with Pedro's
patches breakpoints will be per-symbol-space, not per-inferior, so
we'll have to disable/re-enable all breakpoints in a given symbol
space (we cannot really disable all breakpoints of a given inferior,
as this information is not actually known).

So it seems that after all adding the flag to struct inferior now
might be a step in the wrong direction; it should instead be added to
struct symbol_space once Pedro's patches are in.

Pedro, any comments?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com