From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id A0DD53857829 for ; Tue, 23 Mar 2021 18:55:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org A0DD53857829 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 12NItDUe022657 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 23 Mar 2021 14:55:18 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 12NItDUe022657 Received: from [10.0.0.11] (192-222-157-6.qc.cable.ebox.net [192.222.157.6]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 524B71E939; Tue, 23 Mar 2021 14:55:13 -0400 (EDT) Subject: Re: [PATCH] gdb: Change init order so pretty printers are set in new_objfile event To: Andrew Burgess , Michael Weghorn Cc: gdb-patches@sourceware.org References: <20210210154053.82927-1-m.weghorn@posteo.de> <20210211094234.GM265215@embecosm.com> From: Simon Marchi Message-ID: Date: Tue, 23 Mar 2021 14:55:13 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <20210211094234.GM265215@embecosm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Tue, 23 Mar 2021 18:55:13 +0000 X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2021 18:55:29 -0000 > 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