From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id A2BCC3858C51 for ; Mon, 23 May 2022 17:23:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A2BCC3858C51 Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-137-BLWP9N7nNWuq0nf5rk0nWA-1; Mon, 23 May 2022 13:23:01 -0400 X-MC-Unique: BLWP9N7nNWuq0nf5rk0nWA-1 Received: by mail-wr1-f72.google.com with SMTP id p10-20020adfaa0a000000b0020c4829af5fso4208680wrd.16 for ; Mon, 23 May 2022 10:23:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=8+bHoJjurozcgF9zf4COldj+pJEPScxD5NLVDq6DYAU=; b=XjKMcFPGM+n5dRBq9q90q8FOx3tQ0Jx/8S9AG0RSOzlr2LxdpJ54j29W9+VCSykVyF QlQwgA/GdzzQk/y8vFP+96bP2qwlonE0I0n2eHBnF6UkpY3f80yRVfILeiOM1V8tmaJP yM3RN/Pf72h2UuF3yNS2uVC563nc6AbcIB41AQmqkTQX4ZRhTW60Z5h+0F5YhJYp2SZr q03BtZsokkKr7drp+9CU84HZ9ln+aiYIjT7QFdS1+MwAwjilBIoXfvrUm/2f3RYKHYkb qSF6u9H+c+q8wGJKkSS+zU99nXOBey90NdyYnIF19+CiDW1P3restw7TVogCsPlw0f8n bqAA== X-Gm-Message-State: AOAM532jFQemfQxbWJcqMgzlBRDyuGEIeq6Hc5/9M0HJaBS+aUXEGyWS X5UzNPvifvq7KVj3Fq8wD9d1tGZoeeLF8sNkRBTU0NJDNH2wWgCZAsuuquvYDLz3bI1TlHTw4H4 fojOostZ/k9r9Vv/A1TwuZTKzMQcz6MlOpFE86FmB+bQ8MK91KIAsLzE5JDWPfOqLCSTHNUl7Wg == X-Received: by 2002:a05:6000:188e:b0:20f:e84c:1de9 with SMTP id a14-20020a056000188e00b0020fe84c1de9mr2843192wri.304.1653326580092; Mon, 23 May 2022 10:23:00 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzEvPBOIvJAPvwnLSHpNPy9NUwSBnj0Mb1vTOphCAvx38AsAiD3sLUKlr0DSS41em8367s2kw== X-Received: by 2002:a05:6000:188e:b0:20f:e84c:1de9 with SMTP id a14-20020a056000188e00b0020fe84c1de9mr2843169wri.304.1653326579821; Mon, 23 May 2022 10:22:59 -0700 (PDT) Received: from localhost (host109-154-214-95.range109-154.btcentralplus.com. [109.154.214.95]) by smtp.gmail.com with ESMTPSA id n9-20020adf8b09000000b0020d0931b48asm10788097wra.37.2022.05.23.10.22.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 23 May 2022 10:22:59 -0700 (PDT) From: Andrew Burgess To: Ilya Leoshkevich via Gdb-patches , Tom Tromey Cc: Ulrich Weigand , Andreas Arnez , Ilya Leoshkevich , gdb-patches@sourceware.org Subject: Re: [PATCH v2] gdb: do not add const sections to the section map In-Reply-To: <87mtf8i3e2.fsf@redhat.com> References: <20220517200308.2535419-1-iii@linux.ibm.com> <87mtf8i3e2.fsf@redhat.com> Date: Mon, 23 May 2022 18:22:57 +0100 Message-ID: <87k0aci2oe.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-13.0 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, KAM_SHORT, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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: Mon, 23 May 2022 17:23:08 -0000 Andrew Burgess writes: > I know there's been a little discussion of this patch on the v1 thread, > but I wanted to record my thoughts, and here seemed the better place. > > Ilya Leoshkevich via Gdb-patches writes: > >> From: Ulrich Weigand >> >> build_objfile_section_table () creates four synthetic sections, which >> significantly slow down section map sorting. This is especially >> noticeable when debugging JITs that report a lot of objfiles. Since >> these sections are not useful for find_pc_section (), do not add them >> to the section map. > > This description could really be fleshed out a little more. > > You say "which significantly slow down section map sorting", but I'd > like this to say which sort(s), in which function(s), otherwise I'm > expected to either know, or go figure it out myself. > > You then jump to say the sections are not useful for "find_pc_section", > but it's not immediately obvious how that relates to the change you're > making. > > I think you should spell out that insert_section_p is only used by > update_section_map, which updates the struct objfile_pspace_info > sections table, which is only used from find_pc_section. Then you'd > need to explain why non of these sections can ever be returned from > find_pc_section, though it's not clear (from the discussion on the v1 > thread) if the ABS section might be returned in some cases or not.. > > I tracked down the patch which I think originally added these synthetic > sections, though I don't know if this helps much: > > https://sourceware.org/pipermail/gdb-patches/2013-February/100257.html > > >> --- >> v1: https://sourceware.org/pipermail/binutils/2022-May/120863.html >> v1 -> v2: Fix code style, post to the correct mailing list (Andrew). >> >> gdb/objfiles.c | 5 +++++ >> 1 file changed, 5 insertions(+) >> >> diff --git a/gdb/objfiles.c b/gdb/objfiles.c >> index 80f68fda1c1..8a297c57530 100644 >> --- a/gdb/objfiles.c >> +++ b/gdb/objfiles.c >> @@ -1005,6 +1005,11 @@ insert_section_p (const struct bfd *abfd, > > You'll need to update the comment just before this function. > >> if ((bfd_section_flags (section) & SEC_THREAD_LOCAL) != 0) >> /* This is a TLS section. */ >> return 0; >> + if (bfd_is_const_section (section)) >> + { >> + /* This is one of the global *ABS*, *UND*, *IND*, or *COM* sections. */ >> + return 0; >> + } >> >> return 1; >> } > > The final thing I think you need to add with this patch is some > testing. We don't have much (that I'm aware of) in the way of > performance testing, but what we can do, is add a mechanism by which we > can gather performance data. > > Below you will find a patch that extends one of the existing JIT tests > to gather performance data. I tried this before and after applying your > patch, and I can confirm that the performance improvement with your > change is significant. I think something like this should be included > with this patch. FYI, here's a graph of the performance change I'm seeing when loading 500 JIT ELF files: https://ibb.co/kQrGjtb Thanks, Andrew