From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id 0DE4F396D833 for ; Thu, 19 May 2022 17:37:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0DE4F396D833 Received: from pps.filterd (m0098394.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 24JG7psn000397; Thu, 19 May 2022 17:37:11 GMT Received: from ppma03ams.nl.ibm.com (62.31.33a9.ip4.static.sl-reverse.com [169.51.49.98]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3g5s0ut6jv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 19 May 2022 17:37:11 +0000 Received: from pps.filterd (ppma03ams.nl.ibm.com [127.0.0.1]) by ppma03ams.nl.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 24JHSuDd023817; Thu, 19 May 2022 17:37:09 GMT Received: from b06cxnps4076.portsmouth.uk.ibm.com (d06relay13.portsmouth.uk.ibm.com [9.149.109.198]) by ppma03ams.nl.ibm.com with ESMTP id 3g2429fn5f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 19 May 2022 17:37:08 +0000 Received: from d06av23.portsmouth.uk.ibm.com (d06av23.portsmouth.uk.ibm.com [9.149.105.59]) by b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 24JHb44640894918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 19 May 2022 17:37:04 GMT Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 318D4A4040; Thu, 19 May 2022 17:37:04 +0000 (GMT) Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 055FBA4053; Thu, 19 May 2022 17:37:04 +0000 (GMT) Received: from [9.155.208.113] (unknown [9.155.208.113]) by d06av23.portsmouth.uk.ibm.com (Postfix) with ESMTP; Thu, 19 May 2022 17:37:03 +0000 (GMT) Message-ID: Subject: Re: [PATCH] gdb: do not add const sections to the section map From: Ilya Leoshkevich To: Tom Tromey Cc: Ulrich Weigand , Andreas Arnez , binutils@sourceware.org Date: Thu, 19 May 2022 19:37:03 +0200 In-Reply-To: <875ym1d0dw.fsf@tromey.com> References: <20220516194209.2470009-1-iii@linux.ibm.com> <875ym1d0dw.fsf@tromey.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.4 (3.42.4-2.fc35) X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: sQNgR13RL_enF9t9Y6F5_oW2GjAnYaji X-Proofpoint-GUID: sQNgR13RL_enF9t9Y6F5_oW2GjAnYaji Content-Transfer-Encoding: 8bit X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.874,Hydra:6.0.486,FMLib:17.11.64.514 definitions=2022-05-19_05,2022-05-19_03,2022-02-23_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 bulkscore=0 adultscore=0 suspectscore=0 spamscore=0 mlxlogscore=999 lowpriorityscore=0 clxscore=1015 impostorscore=0 priorityscore=1501 phishscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2205190101 X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, 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: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2022 17:37:15 -0000 On Thu, 2022-05-19 at 09:10 -0600, Tom Tromey wrote: > > > > > > Ilya Leoshkevich 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. > > How does it slow down the sorting? CoreCLR JIT reports each compiled function as a separate objfile with a single .text section and a few debug sections [1]. Once you have a few thousand of them - which is easily reachable - std::sort becomes a bottleneck. Ignoring synthetic sections from each objfile reduces the amount of sections to sort significantly. That's unfortunately not quite enough to debug bigger apps. But it's still a noticeable improvement, so I've decided to post it. I'm currently trying to implement a more complex optimization in the section map area ([2] - not working yet, and probably not reviewable either, just FYI). > It seems a little strange at least to drop the *ABS* section, since > IIUC > that's for symbols that specify some kind of absolute address.  > Couldn't > these matter for lookup purposes?  It's probable I don't really know > what's going on here... All four seem to have a size of 0, so they should never be returned by find_pc_section (). > I wonder if we can drop all support for all these sections from gdb. They were added in 65cf35635977, which introduced gdb_bfd_section_index (). This function is used in quite a few places, so I guess as long as bfd can report these sections, this should stay? > Tom [1] https://github.com/dotnet/runtime/blob/v6.0.5/src/coreclr/vm/gdbjit.cpp#L2147 [2] https://github.com/iii-i/binutils-gdb/releases/tag/section-map-20220519