From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) by sourceware.org (Postfix) with ESMTPS id 5CB1F385BF83 for ; Mon, 6 Apr 2020 11:31:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 5CB1F385BF83 Received: by mail-il1-x12c.google.com with SMTP id f16so14253234ilj.9 for ; Mon, 06 Apr 2020 04:31:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=/zuJ0d9kkpzsdq5+wBFe6Bzu12sc7DQ8ieSaxYJ/69w=; b=c2g2+5k3fOpBaOkmhYX4rrjItzoI7ii9LP4FGUEiyV0y9v6yoQxOENAV0crNUH6TSr cl7IJn4ULiUS7ZXmwQM8DqLiy+9D8nEfPPKrPidTz3ASuNe2jSeLOKja6341ySTxRtyt UllomBlae4k4k9QXajrYExu5o3B8ksgHWho11xU8wIqUSAOBhHnlyMlDih1HGDZ+QFdY OzUq7Y3Fvjp+w+uAIGZElaSYB9EthB1PkvZ953NQ9PX9Uc9TekFQZYb2djIpLKr8662r SyW1hy1bQtGgFo74qfIi/IdYCei1Sl/tc0NCZopF4Vj8SJqT7bNde9rJnRjL5l8rRjYx x5Bw== X-Gm-Message-State: AGi0PuaTxIN1oz4g80gb1jvH++mEZQpfnhaMzSMBUffVHtKGZzLdhZec HNg986fiJLu4y5c+EUiZkPAyD+kGSI0VkQ68FQT/w0nv X-Google-Smtp-Source: APiQypK58/T09COLyuewv/4CT2dhqbR6NtkIeaZMA44U+Z/cEkUtBHlAt+ibmcFBg4E0yryc7POUZNh+jrVvDjp27f4= X-Received: by 2002:a92:83d8:: with SMTP id p85mr21254634ilk.79.1586172714801; Mon, 06 Apr 2020 04:31:54 -0700 (PDT) MIME-Version: 1.0 References: <87blohl3an.fsf@redhat.com> <20200330084522.GA1075780@host1.jankratochvil.net> <20200330091934.GA1078028@host1.jankratochvil.net> In-Reply-To: <20200330091934.GA1078028@host1.jankratochvil.net> From: Norbert Lange Date: Mon, 6 Apr 2020 13:31:43 +0200 Message-ID: Subject: Re: Automatically fetching Build ID from remote libraries and resole them locally? To: Jan Kratochvil Cc: "Frank Ch. Eigler" , gdb@sourceware.org, Gary Benson Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2020 11:31:56 -0000 Am Mo., 30. M=C3=A4rz 2020 um 11:19 Uhr schrieb Jan Kratochvil : > > On Mon, 30 Mar 2020 11:04:30 +0200, Norbert Lange wrote: > > I would want to use 'set sysroot /path/to/staging/dir', but the downsid= e is that > > mismatches will not be detected and can badly mess up debugging. > > You should have setup symlinks in /usr/lib/debug/.build-id/ > (or where you 'set debug-file-directory') for all build-ids you ever buil= d. > That works for core-files. Thats the plan. I verified that the coredump contains all Build-Ids with eu-unstrip -n --core /tmp/core But Id have to first locate the binary manually, then starting gdb PATH_TO_BINARY PATH_TO_CORE Whats worse is, that gdb seems to lookup for the library first (filepath), if it exists it will use the Build-Id from this potentially unrelated version (and use the wrong debug info if one exists), if it does not exist, then it wont even try searching in the debug-library (neither via name or build-id). In other words, its completely broken unless the system you debug is the very same (and in the same state) as the executable did run on. If I'd want to debug a coredump now, I would have to inspect the buildids, copy the debug-infos under the name they where used on the target in a own sysroot. (Almost the same as for remote debug now). I tried both with sysroot unset (default) and set to a directory with partially missing/outdated versions. > > GDB 9.0 certainly does not use *Build-Ids from the 'remote'*, > > According to a test I have made now I agree. Maybe Gary Benson will sugge= st > more. Norbert