Re: [RFC,v2] Yank out target_ops->to_sections

[Pedro Alves <pedro at codesourcery dot com>]

On Tuesday 02 June 2009 12:05:43, Ulrich Weigand wrote:
> > There still needs to be a global somewhere, there's no way around it,
> > but, it will be the "current_symbol_space", not the target sections.
> > This global is then switched whenever we need to switch context
> > --- switch thread, insert breakpoints, or by user command, to e.g.,
> > prepare to start a new inferior --- in a sense, this structure holds
> > the globals that currently form a "prototype" for an inferior.
> 
> This is the one part I'm not sure I agree with. ?I would have hoped
> we could actually get *rid* of all those globals, at least as far
> as the GDB core is concerned. ?(There may be globals in the UI code
> where it makes sense, to represent conceptually global settings at
> the the UI level like the notion of the "selected frame". ?But all
> of GDB's core should IMO be fully parameterized and not rely on
> globals. ?
> I'd expect this could be achieved by passing "inferior" 
> or "thread" arguments to some of the central functions ...)

I don't think anyone disagrees with that.  With my proposal, there will
be ways to get from a frame/thread/inferior/whatever to the corresponding
address/symbol space, and where possible we'll use those.  However,
consider the case where you have more than one program
loaded (say, /bin/cat and /bin/echo), and haven't started execution in
either of those yet.  There is no "inferior" or "thread" object yet
for any of them, and you can't distinguish with inferior_ptid 
either (it's null_ptid in both cases).  Currently, all this state
is spread around in globals all over (e.g., even exec_bfd can be
accessed in the most twisted code paths).  But, it's the "prepare to
start a new inferior" part that ends up requiring the global.  I'm
proposing to aggregate them somewhere, but we still need to have a
global storing a pointer to the "current context" somewhere.  I agree
that ideally then this global should only be accessed at high
layers, close to the UI, and that we should only need to pass to each
major component what it really needs and handles, as arguments.
But, that really *has* to be a long term goal.  Just getting rid
of a single one of those globals (by passing them in arguments) is
a *lot* of hair for practically 0 gain at this point.  Since we do
have to aggregate and store these globals somewhere, I think that
I'm taking a good first step.  IMO, it's much better to just switch
a pointer than to come up with the old "infrun.c|thread.c:context_switch"
mess.  We can then *incrementally* clean up interfaces, as we'll
then have a clearly visible goal to achieve.  Anyway, things
will surely get clearer a bit further down the line when I post
the main juicy bits for discussion.

-- 
Pedro Alves