From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27735 invoked by alias); 11 Jan 2020 13:35:03 -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 27721 invoked by uid 89); 11 Jan 2020 13:35:03 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-8.7 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_1,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=polymtl.ca, UD:polymtl.ca, HX-Languages-Length:1469, polymtlca 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; Sat, 11 Jan 2020 13:35:01 +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 00BDYqwh000311 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 11 Jan 2020 08:34:57 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 00BDYqwh000311 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=polymtl.ca; s=default; t=1578749698; bh=L/TzCnS8rl1ej92+iZ3ldTCPsD3n+qhLp1Z0cViswLk=; h=Subject:To:References:From:Date:In-Reply-To:From; b=bArSte0CEO4xksVxV/3LrJjjyJG0GtmIzFuj/n8vKzDZ8hbr5sbBryDMawFtywHno orokGhXl33m1bNiRnrjho63dy8Msjcm7bHxAuEIqnXVIQxa0zEJonq1+hXSvPZ1ehZ KqVjl/vg863x0x0C6AP1nj6CAVSOCUfiZsbktvbQ= Received: from [10.0.0.11] (unknown [192.222.164.54]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id CEDF31E4C2; Sat, 11 Jan 2020 08:34:52 -0500 (EST) Subject: Re: [PATCH] Dwarf 5: Handle debug_str_offsets and indexed attributes that have base offsets. To: Ali Tamur , gdb-patches@sourceware.org References: <20200111034542.57319-1-tamur@google.com> From: Simon Marchi Message-ID: <487d0942-b589-6007-8ff0-ad38cdab08e8@polymtl.ca> Date: Sat, 11 Jan 2020 13:35:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.3.0 MIME-Version: 1.0 In-Reply-To: <20200111034542.57319-1-tamur@google.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2020-01/txt/msg00286.txt.bz2 On 2020-01-10 10:45 p.m., Ali Tamur via gdb-patches wrote: >> Could this be >> cu->addr_base = lookup_addr_base (die); > gdb.dwarf2/fission-base.exp consistently failed when I tried your suggestion, > and now I am scared whether it is a safe change. (I don't understand the > control flow well, but if cu->addr_base was assigned previously and > lookup_addr_base fails, it would unassign the previous value. Yeah, I'm not sure either. I'm fairly confident that if, for some reason, the field is already set, then it would set it to the same value. After all, stub_comp_unit_die is the stub DIE that corresponds to the DWO file we are reading. If for some reason, there is already a value in cu->addr_base, then it must come from this DIE. If your tests pass, I think we can leave it like this, but of course that can be changed if that proves to be wrong. >> what is the reason we need to have two separate loops here again? > Converted to a single loop. > >> What happens if we encounter one these indirect string forms (strx and >> company) here, but we don't enter any of the two "if" clauses above? > I think that means an incorrect DWARF; I removed the if condition, so the > complaint in read_stub_str_index will trigger. Ok, that's fine with me, it will error out immediatly in that case. The patch LGTM, but I think we are just missing a ChangeLog entry? Simon