From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) by sourceware.org (Postfix) with ESMTPS id 37B83385B835 for ; Mon, 30 Mar 2020 09:04:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 37B83385B835 Received: by mail-il1-x130.google.com with SMTP id k29so15004255ilg.0 for ; Mon, 30 Mar 2020 02:04:42 -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=SdwdRKaZqTYX9lra6higwhyclBtauk0q0TKA6WmpEB4=; b=aGpFkvJ3l77Qz+JfMClGzLBKBIUVQCdJGKTYa7Ucgmi0+dfn0Cmb+otutNJvX6WywK Gpx63hwPuSkkMCD9Bh4dduBavc8it9Kl+2DyooFxLcTynmYXRrcTFNEZFKb3OQAaGcvA ZLoMScEfPUzVclfJeWORp9/w2PZRsoIZtxi32xtnsnYhi8UVL3ozRKso1zLWJ7N4ijcC maTeKQxPpV9rVm58b6jVG9oURXiDD9QgLoi82mBnidNteF/1OwuKsX2HqDAk+0tvZvF4 ze/KdAx3Hs7aW2MjaMdGGR18nCd9lSGpa4VdXjggd36cHEJDfMUPd2oJqLosedSyt9TZ yBew== X-Gm-Message-State: ANhLgQ24oMDBp/USmN2tJ96mZK4W8N6E1rxWG1rvPxsiVTGUqQlGeP/a 7Bl+2JUgsX8tn+6A4Op1NG/musUofr71a8iCo/s= X-Google-Smtp-Source: ADFU+vuGBiEfmaDt/cHfikN/ax3z4CrX4JXvfFJV7PxXZNrPWW53UpksD1MQNEsbXFZiFk8spQKWMR800y4cn30xgdw= X-Received: by 2002:a92:a312:: with SMTP id a18mr3593249ili.249.1585559081705; Mon, 30 Mar 2020 02:04:41 -0700 (PDT) MIME-Version: 1.0 References: <87blohl3an.fsf@redhat.com> <20200330084522.GA1075780@host1.jankratochvil.net> In-Reply-To: <20200330084522.GA1075780@host1.jankratochvil.net> From: Norbert Lange Date: Mon, 30 Mar 2020 11:04:30 +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=-3.8 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, 30 Mar 2020 09:04:43 -0000 Am Mo., 30. M=C3=A4rz 2020 um 10:45 Uhr schrieb Jan Kratochvil : > > On Mon, 30 Mar 2020 10:35:30 +0200, Norbert Lange via Gdb wrote: > > Currently its not possible to detect the Build ID without transferring = the > > whole library from Remote target to the local gdb. I suppose with cored= umps > > its a similar problem. What I would like is using build IDs wherever > > possible. That means retrieve them from the remote, and maybe define so= me > > fileformat to augment coredumps with the information. > > Coredumps already contain build-ids of executables + shared libraries as = long > as it is enabled (it is by default): > https://www.kernel.org/doc/Documentation/filesystems/proc.txt > - (bit 4) ELF header pages in file-backed private memory areas (it is > effective only if the bit 2 is cleared) > > build-id loading from remote files should be also somehow supported by re= cent > GDBs (done by Gary Benson). Thats great then. > > Fedora+RHEL GDB has patchset > https://src.fedoraproject.org/rpms/gdb/blob/master/f/gdb-6.6-buil= did-locate.patch > https://src.fedoraproject.org/rpms/gdb/blob/master/f/gdb-6.6-buil= did-locate-solib-missing-ids.patch > https://src.fedoraproject.org/rpms/gdb/blob/master/f/gdb-6.6-buil= did-locate-core-as-arg.patch > to locate appropriate executable + shared libraries from such core file b= y > build-id - it locates then through symlinks in: > /usr/lib/debug/.build-id/6b/6cd649300ec28b47638e766e9cbb58648cbda= c{,.debug} > > IIUC that patchset should be now being replaced by the elfutils debuginfo= d. Still thinking you are misunderstanding me, debuginfod aint helping here. I am running gdbserver on 'remote' and gdb on 'localpc', then attaching to the remote target. I have a version of the libraries on 'localpc' (almost mirrored for compiling), but they might not be the exact ones used on the 'remote' (rebuilds, additional libs, etc.= .) I would want to use 'set sysroot /path/to/staging/dir', but the downside is= that mismatches will not be detected and can badly mess up debugging. GDB 9.0 certainly does not use *Build-Ids from the 'remote'*, neither for files existing on the 'localpc' or not (used strace to monitor the file lookups). I could only set 'set sysroot target:/', at which point all DSOs will be transmitted from 'remote' to 'localpc'. Not exactly what I had in mind. So, instead I would want GDB to just inspect the Build-ID's from 'remote', and look them up from 'localpc' (whether its using debuginfod or not, this is irrelevant here). Norbert