From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13072 invoked by alias); 29 Apr 2017 01:13:14 -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 13049 invoked by uid 89); 29 Apr 2017 01:13:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 29 Apr 2017 01:13:11 +0000 Received: from svr-orw-mbx-03.mgc.mentorg.com ([147.34.90.203]) by relay1.mentorg.com with esmtp id 1d4Gwh-0000xt-5s from Luis_Gustavo@mentor.com ; Fri, 28 Apr 2017 18:13:11 -0700 Received: from [172.30.15.191] (147.34.91.1) by svr-orw-mbx-03.mgc.mentorg.com (147.34.90.203) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 28 Apr 2017 18:13:07 -0700 Reply-To: Luis Machado Subject: Re: [PATCH] Fix PR 21337 v2: segfault when re-reading symbols with remote debugging. References: <20511c76-c816-d31d-5144-749eac9fc470@imgtec.com> <3c5ce0a0-72e5-4460-5555-ad2214866260@imgtec.com> <5c494cc147f71dd8246572aa0b815c9f@polymtl.ca> <7e9595026acbfd2f1a7bff321fa255e1@polymtl.ca> To: Doug Gilmore , Simon Marchi CC: From: Luis Machado Message-ID: Date: Sat, 29 Apr 2017 01:13:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: SVR-ORW-MBX-09.mgc.mentorg.com (147.34.90.209) To svr-orw-mbx-03.mgc.mentorg.com (147.34.90.203) X-IsSubscribed: yes X-SW-Source: 2017-04/txt/msg00816.txt.bz2 On 04/28/2017 06:44 PM, Doug Gilmore wrote: >> ... >> /* We use the same section offsets as from last time. I'm not >> sure whether that is always correct for shared libraries. */ >> objfile->section_offsets = (struct section_offsets *) >> obstack_alloc (&objfile->objfile_obstack, >> SIZEOF_N_SECTION_OFFSETS (num_offsets)); >> memcpy (objfile->section_offsets, offsets, >> SIZEOF_N_SECTION_OFFSETS (num_offsets)); >> objfile->num_sections = num_offsets; >> >> so it should not be the culprit... The s variable itself should point to an instance of obj_section, contained in the objfile_pspace_info::sections array. This one is allocated with XNEWVEC, so it shouldn't be affected by the fact that we clear the obstack. >> >> The objfile object itself doesn't change address, so the pointers to it should still be valid... >> >> I find the obj_section_addr and obj_section_offset very bad for readability and debuggability. Could you change them for inline functions that are not one liners? Then it will be obvious in the backtrace which operation causes the crash. >> >> Thanks, >> >> Simon > Hi Simon, > > After thinking about it my comment and code placement wasn't > particularly good. Something along the line's of Luis's change > is better. > > Does Luis's comment address the question you have? > > If so, Luis: Should is it OK we incorporate your changes in the patch? Sure. I have no problems with that.