Re: [PATCH] gdb: Change init order so pretty printers are set in new_objfile event

[Andrew Burgess <andrew.burgess@embecosm.com>]

* Simon Marchi <simon.marchi@polymtl.ca> [2021-03-23 14:55:13 -0400]:

> > I have a crazy thought, but I want to mention it in case it has any
> > value.
> > 
> > The core of the idea is to modify the attach functions in
> > gdbsupport/observable.h like this:P
> > 
> >   void attach (const func_type &f, int bias = 0)
> >   {
> >     m_observers.emplace_back (nullptr, f, bias);
> >     if (m_sorted || bias != 0)
> >       {
> > 	m_sorted = true;
> > 	std::sort (m_observers.begin (), m_observers.end (), sort_by_bias);
> >       }
> >   }
> > 
> > Where 'm_sorted' is just a boolean flag, and `sort_by_bias` just
> > orders the observers from highest bias to lowest.  Then, if you have
> > an observer that you want to run late in the process you just attach
> > it with a low bias.  So in py-inferior.c:
> > 
> >   /* Pass a low bias to ensure this observer triggers after any
> >      GDB internal observers.  */
> >   gdb::observers::new_objfile.attach (python_new_objfile, -10);
> > 
> 
> I had similar crazy thoughts once.  Except it wouldn't use arbitrary
> numerical values.  It can be a bit obscure why a certain value is
> assigned to a given observer.
> 
> Instead, when attaching an observer you tell which other observer you'd
> like to run after.  So let's say subsystem bar uses features from
> subsystem foo (so it necessarily knows about foo already), foo would do:
> 
>   // In foo.h
>   extern observer_key foo_new_objfile_observer;
> 
>   // In foo.c, in _initialize_foo
>   foo_new_objfile_observer = gdb::observers::new_objfile.attach (foo_new_objfile);
> 
>   // In bar.c, in _initialize_bar
>   gdb::observers::new_objfile.attach (bar_new_objfile, &foo_new_objfile_observer);

That's fine, but I ran into a case just a couple of days ago where I
wanted observer ordering, but in that case there are two observers
that I would have wanted to be ordered before.

I guess we could chain the dependencies, but I suspect this would
break if observers are detached (e.g. tui observers).

I think the only reliable solution would be to allow for a vector of
dependencies, how would that sound?

Thanks,
Andrew