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

[Simon Marchi <simon.marchi@polymtl.ca>]

> 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);

We could then sort the observers in a way that they are all satisfied.
Unless there are some cycles, but we should detect those and abort.  I
think that by passing a pointer to the observer_key, it should be
possible to make it work regardless of in which order the two attach are
done (since we don't control the order of the _initialize calls).

Simon