From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 91299 invoked by alias); 16 Jun 2019 17:41:58 -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 91273 invoked by uid 89); 16 Jun 2019 17:41:58 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-15.9 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=20190507, 2019-05-07, 20190610, H*M:7999 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; Sun, 16 Jun 2019 17:41:57 +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 x5GHfk14011911 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 16 Jun 2019 13:41:51 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca x5GHfk14011911 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=polymtl.ca; s=default; t=1560706913; bh=ofS+Guh/0vSDyPgsofkqtsdKMdssPDuPKK7k9PP8hW4=; h=Subject:To:References:From:Date:In-Reply-To:From; b=gIThobTADAhh8fpcsCdj3VRa/K+Qu3f6ZhwT0o1FVlD19zXUTry6f/Rn06UsLwume 2h1xC8xAyEMCFICoudZuuB8LBK2cqt4iDD1zvjPAq0rjhovyXHrfEIFudYLqovx5ls 2vxzZzO283+YZIWP5zGPkEFnxtf7NeDnAid4vtUE= Received: from [10.0.0.11] (unknown [192.222.164.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 5DF2F1E4C2; Sun, 16 Jun 2019 13:41:46 -0400 (EDT) Subject: Re: [PATCH, gdb/contrib] Fix gdb/contrib/gdb-add-index.sh for dwz-m-ed execs To: Tom de Vries , gdb-patches@sourceware.org, Pedro Alves References: <20190507144207.GA17626@delia> <852d3210-f59a-1540-ed23-19f31829f465@polymtl.ca> <4899dcce-cb5c-27a7-9f21-d230e13485cd@suse.de> <754e9866-69a8-8f20-e325-789096e6b14f@suse.de> From: Simon Marchi Message-ID: <2e681f66-d85a-7999-54a8-90b3a7230794@polymtl.ca> Date: Sun, 16 Jun 2019 17:41:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <754e9866-69a8-8f20-e325-789096e6b14f@suse.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-06/txt/msg00292.txt.bz2 On 2019-06-10 2:41 p.m., Tom de Vries wrote: > On 13-05-19 12:47, Tom de Vries wrote: >> On 12-05-19 21:49, Simon Marchi wrote: >>> On 2019-05-07 12:13 p.m., Tom de Vries wrote: >>>> [ was: Re: [PATCH][gdb] Write index for dwz -m file ] >>>> >>>> >>>> Hi, >>>> >>>> This is a follow-up patch for "[gdb] Write index for dwz -m file". >>>> >>>> Any comments on the updated gdb/contrib/gdb-add-index.sh script? >>>> >>>> In particular, I'd like some advice on whether I should add shell >>>> variables (as I've done for readelf) for grep, tail and sed. >>>> >>>> Thanks, >>>> - Tom >>>> >>> Hi Tom, >>> >>> I think it can be useful to override gdb, readelf and objcopy, as it is likely >>> that people will want to use specific versions of these (either newer, or >>> specific to their architectures). >>> >>> But it's not very likely for grep, tail and sed, as long as we make sure that >>> we are compatible with the BSD versions of these tools. That would mean making >>> sure we only use features defined by POSIX. >>> >> Ack, thanks for the insight. >> >>> One case that isn't handled correct by GDB and/or the script (with both my and >>> your patch applied) is running the script on two executables that share the same >>> external dwz file. It will fail adding the index to the dwz file the second time. >>> This use case is kind of important, because the point of having dwz files is to >>> share it between multiple executables. >>> >>> This is what I get the second time: >>> >>> $ GDB="/home/simark/build/binutils-gdb/gdb/gdb --data-directory=/home/simark/build/binutils-gdb/gdb/data-directory" ~/src/binutils-gdb/gdb/contrib/gdb-add-index.sh b >>> + objcopy --add-section .gdb_index=shared-debug-info.dwz.gdb-index --set-section-flags .gdb_index=readonly shared-debug-info.dwz shared-debug-info.dwz >>> objcopy:std9IdCI: can't add section '.gdb_index': file in wrong format >>> >>> I haven't looked in more details for this problem. >>> >> That's fixed now. >> >> [ In a way, it's a known problem. Running gdb-add-index twice on the >> same (regular, non-dwz-ed) executable, gives the same kind of error. ] >> >>> There's a buglet in the clean up code causing the dwz file's index >>> (shared-debug-info.dwz.gdb-index in my case) to be left in the current directory after >>> running the script (even successfully). This fixes it: >>> >>> --- >>> diff --git a/gdb/contrib/gdb-add-index.sh b/gdb/contrib/gdb-add-index.sh >>> index afedce0c848d..2b3af2e84f71 100755 >>> --- a/gdb/contrib/gdb-add-index.sh >>> +++ b/gdb/contrib/gdb-add-index.sh >>> @@ -70,7 +70,7 @@ for f in "$file" "$dwz_file"; do >>> if [ "$f" = "" ]; then >>> continue >>> fi >>> - set_files "$file" >>> + set_files "$f" >>> tmp_files="$tmp_files $index4 $index5 $debugstr $debugstrmerge $debugstrerr" >>> done >> Ok, I've incorporated that fix, as well as making the handle_file >> $dwz_file conditional on $dwz_file != "". >> >> Updated version attached. >> > > OK for trunk? > > Thanks, > - Tom Hi Tom, Thanks, this LGTM. Simon