From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 43441 invoked by alias); 26 Jun 2018 13:26:28 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 43432 invoked by uid 89); 26 Jun 2018 13:26:27 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.9 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_1,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: smtp.polymtl.ca Received: from smtp.polymtl.ca (HELO smtp.polymtl.ca) (132.207.4.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 26 Jun 2018 13:26:26 +0000 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 w5QDQKP8023635 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 26 Jun 2018 09:26:24 -0400 Received: by simark.ca (Postfix, from userid 112) id E83661EF28; Tue, 26 Jun 2018 09:26:19 -0400 (EDT) Received: from simark.ca (localhost [127.0.0.1]) by simark.ca (Postfix) with ESMTP id 5E4D51E529; Tue, 26 Jun 2018 09:26:19 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 26 Jun 2018 13:26:00 -0000 From: Simon Marchi To: Petr Tesarik Cc: gdb-patches@sourceware.org Subject: Re: [PATCH v2 3/4] Make sure that sorting does not change section order In-Reply-To: <20180626070943.7331c1d2@ezekiel.suse.cz> References: <20180611120835.27343-1-ptesarik@suse.cz> <20180611120835.27343-4-ptesarik@suse.cz> <2a43d96e7d7c435bb9344dc1825e5be8@polymtl.ca> <20180626070943.7331c1d2@ezekiel.suse.cz> Message-ID: X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.3.6 X-IsSubscribed: yes X-SW-Source: 2018-06/txt/msg00612.txt.bz2 On 2018-06-26 01:09, Petr Tesarik wrote: >> It took me a while to acknowledge that this was correct, because >> other_sections::sectindex usually refers to the section index in the >> BFD. After digging I understood that this field was actually unused >> until filled by addr_info_make_relative, and that you kind of >> re-purposed it. It sounds like there should be some comment at >> other_sections::sectindex and probably in add_symbol_file_command to >> explain how it's used. > > Agreed. As a matter of fact, it also took me some while to understand > why add_symbol_file_command could get away with setting the index to > zero for all sections... > >> Another option would be to use std::stable_sort instead of std::sort. >> But it's more resource-hungry and not needed for all paths that lead >> to >> addrs_section_sort, so it would be a bit wasteful. > > Yes, I tried to avoid that solution. OTOH it's unlikely that there are > any object files with more than a few dozen sections, and to my best > knowledge this code is never in the GDB hot path, so if you prefer > std::stable_sort for clarity, I'm not against. Please, advise. > > Petr T I think you solution is fine, it just needs to be documented that it's intentional that we use some other value than the section index in sectindex. Simon