From patchwork Fri Oct 20 15:33:18 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ulrich Weigand X-Patchwork-Id: 23732 Received: (qmail 95071 invoked by alias); 20 Oct 2017 15:33:28 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 95062 invoked by uid 89); 20 Oct 2017 15:33:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-25.1 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1365 X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0a-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.156.1) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 20 Oct 2017 15:33:27 +0000 Received: from pps.filterd (m0098396.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v9KFVZco041695 for ; Fri, 20 Oct 2017 11:33:25 -0400 Received: from e06smtp13.uk.ibm.com (e06smtp13.uk.ibm.com [195.75.94.109]) by mx0a-001b2d01.pphosted.com with ESMTP id 2dqjuvb99k-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Fri, 20 Oct 2017 11:33:25 -0400 Received: from localhost by e06smtp13.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 20 Oct 2017 16:33:21 +0100 Received: from b06cxnps4075.portsmouth.uk.ibm.com (9.149.109.197) by e06smtp13.uk.ibm.com (192.168.101.143) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 20 Oct 2017 16:33:19 +0100 Received: from d06av24.portsmouth.uk.ibm.com (d06av24.portsmouth.uk.ibm.com [9.149.105.60]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id v9KFXJBi11862098; Fri, 20 Oct 2017 15:33:19 GMT Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E77E542042; Fri, 20 Oct 2017 16:28:48 +0100 (BST) Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D3A724203F; Fri, 20 Oct 2017 16:28:48 +0100 (BST) Received: from oc3748833570.ibm.com (unknown [9.164.174.45]) by d06av24.portsmouth.uk.ibm.com (Postfix) with ESMTP; Fri, 20 Oct 2017 16:28:48 +0100 (BST) Received: by oc3748833570.ibm.com (Postfix, from userid 1000) id AF81FD80819; Fri, 20 Oct 2017 17:33:18 +0200 (CEST) Subject: Re: [RFA 1/6] Use std::vector in end_symtab_get_static_block To: gdb-patches@sourceware.org Date: Fri, 20 Oct 2017 17:33:18 +0200 (CEST) From: "Ulrich Weigand" Cc: tom@tromey.com, simon.marchi@ericsson.com In-Reply-To: <874lqyu53w.fsf@tromey.com> from "Tom Tromey" at Oct 16, 2017 03:58:59 PM MIME-Version: 1.0 X-TM-AS-GCONF: 00 x-cbid: 17102015-0012-0000-0000-00000583D793 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17102015-0013-0000-0000-000018FE3D8C Message-Id: <20171020153318.AF81FD80819@oc3748833570.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-20_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=1 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710200215 [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? Bye, Ulrich diff --git a/gdb/buildsym.c b/gdb/buildsym.c index c556ac1..b6d4e67 100644 --- a/gdb/buildsym.c +++ b/gdb/buildsym.c @@ -1249,7 +1249,7 @@ end_symtab_get_static_block (CORE_ADDR end_addr, int expandable, int required) for (pb = pending_blocks; pb != NULL; pb = pb->next) barray.push_back (pb->block); - std::sort (barray.begin (), barray.end (), + std::stable_sort (barray.begin (), barray.end (), [] (const block *a, const block *b) { /* Sort blocks in descending order. */