From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 86058 invoked by alias); 27 Jan 2020 19:07:42 -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 86046 invoked by uid 89); 27 Jan 2020 19:07:42 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=nasty X-HELO: us-smtp-1.mimecast.com Received: from us-smtp-delivery-1.mimecast.com (HELO us-smtp-1.mimecast.com) (207.211.31.120) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 27 Jan 2020 19:07:41 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1580152059; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=1gh5h1RXFJjcLwI9x90kfzK/7BsLquyhmxEmBoQ3lu0=; b=a8ts9d94EReH4OQvfJQpkqxfXNlvsJKZ4VZqupYIOOXo5Zg2jz7l2TBvEouNmSoD+nxa9V ZjUdxsW5StRqCobzsIbH5OTd6OeQMgcbAnCs6MIxchxYtl0L5FVavJteAHtdK6Syl2vSMn OkrMq3nkViHTZJ0dbx6KXYEMS13hBMs= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-387-sByDd_cLMKuDFX1zpHsBjQ-1; Mon, 27 Jan 2020 14:07:37 -0500 Received: by mail-wm1-f71.google.com with SMTP id p5so1799255wmc.4 for ; Mon, 27 Jan 2020 11:07:36 -0800 (PST) Return-Path: Received: from ?IPv6:2001:8a0:f909:7b00:56ee:75ff:fe8d:232b? ([2001:8a0:f909:7b00:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id r15sm19800776wmh.21.2020.01.27.11.07.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 27 Jan 2020 11:07:35 -0800 (PST) Subject: Re: [PATCH] gdb: Reinitialize objfile::section_offsets during objfile reload To: Tom Tromey References: <20200125225555.16846-1-andrew.burgess@embecosm.com> <875zgy6vo5.fsf@tromey.com> <871rrm6v9r.fsf@tromey.com> Cc: Andrew Burgess , gdb-patches@sourceware.org From: Pedro Alves Message-ID: <62d7db58-b5c4-19ff-f4b5-c019ae310c28@redhat.com> Date: Mon, 27 Jan 2020 20:32:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <871rrm6v9r.fsf@tromey.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2020-01/txt/msg00886.txt.bz2 On 1/26/20 4:24 PM, Tom Tromey wrote: > Andrew> When building and testing with '-D_GLIBCXX_DEBUG=1' I noticed that the > Andrew> test gdb.base/reload.exp was failing. This turns out to be because > Andrew> the objfile::section_offsets vector is not reinitialilzed during the > Andrew> objfile reload process, and in this particular test, GDB ends up > Andrew> indexing outside the bounds of the vector. > > Tom> Thanks for catching this. > > I wonder if this is a regression due to > > commit 6a053cb1ff643cec3349d7f2f47ae5573f82d613 > Author: Tom Tromey > Date: Mon Jan 6 14:34:52 2020 -0700 > > Change section_offsets to a std::vector > > See appended. > > I think at the time I thought removing this code would simply preserve > the offsets. But maybe we instead should std::move the offsets out of > the objfile and then move them back in? +1. Losing the user-specified offsets sounds nasty. Thanks, Pedro Alves