From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 49880 invoked by alias); 20 Oct 2017 16:47:25 -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 49863 invoked by uid 89); 20 Oct 2017 16:47:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=HTo:D*de.ibm.com X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 20 Oct 2017 16:47:23 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C2502C059B69; Fri, 20 Oct 2017 16:47:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com C2502C059B69 Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=palves@redhat.com Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 6E0325D9C1; Fri, 20 Oct 2017 16:47:19 +0000 (UTC) Subject: Re: [RFA 1/6] Use std::vector in end_symtab_get_static_block To: Ulrich Weigand , gdb-patches@sourceware.org References: <20171020153318.AF81FD80819@oc3748833570.ibm.com> Cc: tom@tromey.com, simon.marchi@ericsson.com From: Pedro Alves Message-ID: <3d40d7a8-65d1-3c04-1041-475457acfe48@redhat.com> Date: Fri, 20 Oct 2017 16:47:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20171020153318.AF81FD80819@oc3748833570.ibm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-10/txt/msg00672.txt.bz2 On 10/20/2017 04:33 PM, Ulrich Weigand wrote: > [Re-sent since the original seems to have gotten lost somehow.] > >>>>>>> "Simon" == Simon Marchi writes: >> >> Simon> That made me doubt for a second, since we're more used to see "<" >> Simon> in these functions. I then saw that block_compar did sort them >> Simon> in descending order. Could you add a comment here to indicate that? >> >> Done, thanks. > > This causes a number of regressions in the gdb.opt/inline-cmds.exp > test case for me. Not sure exactly why, but changing the std::sort > to a std::stable_sort like below fixes those regressions for me. > Maybe the logic for handling inline function blocks somehow relied > on some (undocumented) behavior of qsort for handling elements that > compare as equal? > Sounds like we should improve the sort predicate to disambiguate better, define a total order? I don't really know which sorting is assumed, but e.g., if the block start addresses are the same, compare the blocks' end addresses. If those match as well, repeat but with the blocks' superblocks. And/or sort function blocks before non-function blocks. Etc. Thanks, Pedro Alves