From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) by sourceware.org (Postfix) with ESMTPS id 63AC23858002 for ; Wed, 24 Mar 2021 09:45:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 63AC23858002 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=embecosm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=andrew.burgess@embecosm.com Received: by mail-ed1-x533.google.com with SMTP id h10so26813219edt.13 for ; Wed, 24 Mar 2021 02:45:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=jGyxeGCL13Yc4YoxkvA988LEmp2lAhtf/LIQ8bMr+s4=; b=Jh/UjkofyGeKt+G0Ax4IOwjipGn4PQp4EzHaUmITgJc3ocW2U1i73Uo/Vf5bHHHxky dB5+z/kNEMvMjFDDDgcOs8cPSBxCgqtwmMaphoEfM9C8pyW5fLwkmcsIsmK/7QZ3y36Y Vc+UuTa7uqw1vC5CXWNiE2qb/TKZ9ucqM1ZXbd478BzUd7BHW8J+leenXDts4blRVcIq +xbr3VKmwTeuvRNJlMMa1wJDQo5pqPMQkVB4TXqdr3IdrAQX4SR9CzW/rTUVMr2qd2Ed 01z8+0ju1ZPZRCaMvqWnjeQIzYeuwHxzDOMXQOv586XKgjjJMEHszrBWUu4W3WR6K145 XT7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=jGyxeGCL13Yc4YoxkvA988LEmp2lAhtf/LIQ8bMr+s4=; b=mUufoAvLLW9TiZiO/boCHF26yqymhYd1AXmFLPCo0P4/Tbuf5+aIOZ0UpEUKgUnRlA FwjYDN4HxBhTNwXyS4q52+XT0oz/Yq21TCehAEdGvkBU9UNXHJnviZ5R6R7tqxChxqSK R+ra2lUbSA8P4xPgvdvD5RzAfm0rFRfM74U0OuaP2MeYQAXzB1zq0Wc1ym5ImxdwMTHE hqe9ldGBbFSriXyTubJqtB/6B6xq70wdU8c3ZJay0urMZ4JWy5ySpy7AnerkIPba2OaW 13EakKWurKJbjQGz25nNFmPOIz8qCNA7Lgjit+3kCOVJXdoxPcfUnGEk28x+wnim5HXv ucRw== X-Gm-Message-State: AOAM533sO9+xtGXMWct8byNXroCZQcsB79HRgLLq4Wu4yc5HebwPnqyD PS4dNSZ7I+IntD6WmO1XwrP4XA== X-Google-Smtp-Source: ABdhPJxbR8jBmbx0tWJD4+1KPvgkN9bq1elFlV5TbfhfOg0/biGhde8WFRjJTSb32cLCHIYtnkA9Jg== X-Received: by 2002:a05:6402:5252:: with SMTP id t18mr2530932edd.258.1616579125553; Wed, 24 Mar 2021 02:45:25 -0700 (PDT) Received: from localhost (host165-120-118-227.range165-120.btcentralplus.com. [165.120.118.227]) by smtp.gmail.com with ESMTPSA id cb17sm884094edb.10.2021.03.24.02.45.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Mar 2021 02:45:24 -0700 (PDT) Date: Wed, 24 Mar 2021 09:45:23 +0000 From: Andrew Burgess To: Simon Marchi Cc: Michael Weghorn , gdb-patches@sourceware.org Subject: Re: [PATCH] gdb: Change init order so pretty printers are set in new_objfile event Message-ID: <20210324094523.GI5520@embecosm.com> References: <20210210154053.82927-1-m.weghorn@posteo.de> <20210211094234.GM265215@embecosm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Linux/5.8.13-100.fc31.x86_64 (x86_64) X-Uptime: 09:34:50 up 12 days, 16:46, X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, 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: Wed, 24 Mar 2021 09:45:27 -0000 * Simon Marchi [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