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

[Michael Weghorn <m.weghorn@posteo.de>]

On 24/03/2021 14.51, Simon Marchi via Gdb-patches wrote:
>>> 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);

When trying to implement this, it was unclear to me
how to assign something useful to 'foo_new_objfile_observer' and make use
of that elsewhere (in particular since the call from '_initialize_bar' below
may happen before the one from '_initialize_foo' above, i.e. before the
assignment has happened).

I have still tried to implement the approach as I have understood it and am
currently passing the pointer to the key 'foo_new_objfile_observer' as another
param instead, i.e.

    std::vector<objfile_key *> deps;
    gdb::observers::new_objfile.attach (foo_new_objfile,
                                        &foo_new_objfile_observer, deps);

where the second param is now the optional key to use for the observer itself
and the third param is an optional vector of keys for dependencies (explicitly
given her for clarity).
The key is then used for sorting inside of the 'observable::attach' method
(so that observers depending on this one are moved to after it).

I have uploaded my approach as v3:
https://sourceware.org/pipermail/gdb-patches/2021-March/177251.html

I may well have missed or misunderstood something, so am happy for any hints.

>>>
>>>   // 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?
> 
> Do you mean using a vector to be able to specify multiple dependencies
> on attach, like this?
> 
>     std::vector<objfile_key *> deps {&foo1_new_objfile_observer,
> 				     &foo2_new_objfile_observer};
>     gdb::observers::new_objfile.attach (bar_new_objfile, deps);
> 
> ?
> 
> If so, yes I think that makes sense.

v3 of the patch uses a vector for dependencies.
So far, I have only added the dependency for my original scenario and haven't
explicitly tested any more complex cases yet.
I can do so if the patch/approach is generally considered OK.

Michael