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

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

Pedro Alves wrote:
> On Thursday 23 July 2009 17:31:02, Ulrich Weigand wrote:
> 
> > 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?
> 
> Yes, I agree with you.  (although in the only target supporting
> shared symbol space, DICOS, we don't run or start programs, we only
> attach to already running ones, and if we did [it would be possible to
> add such feature], the code is always already all relocated when we
> connect --- due to the global shared libraries feature of DICOS.)
> 
> While Tom's right, there has been a stream of changes recently that
> constantly require that I adjust the multi-exec patch set, I'll handle
> this one easily when your patch is in; I don't think it will
> be much trouble.

Thanks, Pedro!  I've checked the patch in now; if you have any issues
in adapting the multi-exec patch, please let me know; I'd be happy
to help ...

Bye,
Ulrich

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