From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 124148 invoked by alias); 15 Sep 2015 01:37:22 -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 124137 invoked by uid 89); 15 Sep 2015 01:37:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,KAM_LOTSOFHASH,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pa0-f50.google.com Received: from mail-pa0-f50.google.com (HELO mail-pa0-f50.google.com) (209.85.220.50) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 15 Sep 2015 01:37:19 +0000 Received: by pacex6 with SMTP id ex6so159994647pac.0 for ; Mon, 14 Sep 2015 18:37:17 -0700 (PDT) X-Received: by 10.68.233.167 with SMTP id tx7mr40474733pbc.75.1442281037211; Mon, 14 Sep 2015 18:37:17 -0700 (PDT) Received: from seba.sebabeach.org.gmail.com (173-13-178-53-sfba.hfc.comcastbusiness.net. [173.13.178.53]) by smtp.gmail.com with ESMTPSA id ok4sm18523773pbb.65.2015.09.14.18.37.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 Sep 2015 18:37:16 -0700 (PDT) From: Doug Evans To: Jan Kratochvil Cc: gdb-patches Subject: Re: [PATCH v12 00/32] Validate binary before use References: <20150821212006.6673.35100.stgit@host1.jankratochvil.net> <20150902074113.GA32556@host1.jankratochvil.net> <20150902151404.GA12757@host1.jankratochvil.net> <20150902191249.GA17111@host1.jankratochvil.net> Date: Tue, 15 Sep 2015 01:37:00 -0000 In-Reply-To: <20150902191249.GA17111@host1.jankratochvil.net> (Jan Kratochvil's message of "Wed, 2 Sep 2015 21:12:49 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2015-09/txt/msg00302.txt.bz2 Jan Kratochvil writes: > Hello Doug, > > this discussion is offtopic for this patchset and it touches areas I am not > yet sure how I will change/rewrite before posting the linux-nat/corefile next > part. OTOH that's also good as it can be at least designed ahead of coding. Yeah. [FAOD, I'm only seeking information at this point. This particular subthread isn't part of a formal review of the patch.] > On Wed, 02 Sep 2015 17:22:35 +0200, Doug Evans wrote: >> On Wed, Sep 2, 2015 at 8:14 AM, Jan Kratochvil >> wrote: >> > The Fedora patchset intentionally disables build-ids verification/lookup if >> > random-program is specified as it was breaking some compatibility >> >> Interesting. What kind of compatibility? > > I was looking up what it really was and there are two reasons: > > (1) I did not want to change behavior of Fedora fork of GDB against upstream. > This is why I tried to keep the behavior of case > "gdb random-program random-core" > the same as upstream GDB has. > > This can be sure changed now when/if the feature gets upstreamed. > > (2) As discussed below for "Fedora native" loading of core-files fully > according to build-ids any behavior is OK as such case does not work for > upstream GDB at all. In such case the strict build-id matching is the > best one for user IMO as shown in: > non-matching build-id libraries should not be loaded for `gdb -c' > https://bugzilla.redhat.com/show_bug.cgi?id=524572 > + > Base the backtrace strictly on build-id > https://bugzilla.redhat.com/show_bug.cgi?id=525721 Thanks. I think upstream will definitely want the verification if both program + core are provided. [plus a way to turn the verification off!] Set aside vendor-provided binaries. Imagine Joe User has a binary and a core file. Or imagine an entire community of programmers, binaries, and cores. Making sure one is using the right core file with the right program is important. >> > and IMO it >> > does not make sense to specify random-program if build-ids are available. >> >> Why is that? >> [Just because one has a build id doesn't necessarily mean one knows where >> a program is. Or did I misunderstand?] > > On Fedora for build-id -> filename mapping one needs the appropriate > n-debuginfo-v-r.a.rpm installed. IMO on development machines they are > installed most of the time because otherwise Fedora GDB all the time annoys > users by complaints they should get installed. If it is missing for any reason > one can easily get it installed as shown at the end of this mail. (OK, maybe > it can be made even easier but that would require better integration with the > ever-changing packaging front-ends on Fedora.) > > There were some discussions how the build-id -> filename mapping should be > stored. Currently it is done by on-disk symlinks in /usr/lib/debug/.build-id/ > stored in *-debuginfo.rpm (therefore to get just the build-id -> filename > mapping symlink even for an already installed binary one needs to install > *-debuginfo.rpm). > # ls -l /usr/lib/debug/.build-id/b3/e636b621bb16456d201edca942442bdbf045f9* > lrwxrwxrwx 1 root root 21 Jul 16 10:42 /usr/lib/debug/.build-id/b3/e636b621bb16456d201edca942442bdbf045f9 -> ../../../../bin/sleep* > lrwxrwxrwx 1 root root 25 Jul 16 10:42 /usr/lib/debug/.build-id/b3/e636b621bb16456d201edca942442bdbf045f9.debug -> ../../usr/bin/sleep.debug > # rpm -qf /usr/lib/debug/.build-id/b3/e636b621bb16456d201edca942442bdbf045f9{,.debug} /bin/sleep /usr/lib/debug/usr/bin/sleep.debug > coreutils-debuginfo-8.24-2.fc23.x86_64 > coreutils-debuginfo-8.24-2.fc23.x86_64 > coreutils-8.24-2.fc23.x86_64 > coreutils-debuginfo-8.24-2.fc23.x86_64 > > Other possibilities would be to store build-ids into .rpm tags even in the main > binary .rpms; but that would make dependency of the build-ids resolving on rpm. > Another possibility is to include the build-id symlinks into the main binary > packages; but those symlinks can take a lot of disk space even when no > debugging is required. Or to have some global or per-package sqlite database > etc. > > > Jan > > > $ gdb -q core.23526 > [New LWP 23526] > Missing separate debuginfo for the main executable file > Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/b3/e636b621bb16456d201edca942442bdbf045f9 > Core was generated by `sleep 1h'. > Program terminated with signal SIGSEGV, Segmentation fault. > #0 0x00007f2810648bf0 in ?? () > "/home/jkratoch/t/core.23526" is a core file. > Please specify an executable to debug. > (gdb) q > # dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/b3/e636b621bb16456d201edca942442bdbf045f9 > [...] > Installed: > coreutils-debuginfo.x86_64 8.24-2.fc23 > $ gdb -q core.23526 > [New LWP 23526] > Reading symbols from /usr/bin/sleep...Reading symbols from /usr/lib/debug/usr/bin/sleep.debug...done. > done. > > warning: Ignoring non-absolute filename: > Missing separate debuginfo for linux-vdso.so.1 > Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/2b/fef7432912bcc87752ef9e66b1ddb71d7485f5 > Core was generated by `sleep 1h'. > Program terminated with signal SIGSEGV, Segmentation fault. > #0 0x00007f2810648bf0 in __nanosleep_nocancel () from /lib64/libc.so.6 > Missing separate debuginfos, use: dnf debuginfo-install glibc-2.21.90-21.fc23.x86_64 > (gdb) q > # dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/2b/fef7432912bcc87752ef9e66b1ddb71d7485f5 > Last metadata expiration check performed 0:03:45 ago on Wed Sep 2 20:53:07 2015. > No package /usr/lib/debug/.build-id/2b/fef7432912bcc87752ef9e66b1ddb71d7485f5 available. > Error: no package matched > --- Because matching kernel.rpm running on host OS is not available in this guest OS. > # dnf debuginfo-install glibc-2.21.90-21.fc23.x86_64 > [...] > Installed: > glibc-debuginfo.x86_64 2.22-2.fc23 glibc-debuginfo-common.x86_64 2.22-2.fc23 nss-softokn-debuginfo.x86_64 3.20.0-1.0.fc23 > $ gdb -q core.26016 > [New LWP 26016] > Reading symbols from /usr/bin/sleep...Reading symbols from /usr/lib/debug/usr/bin/sleep.debug...done. > done. > > warning: Ignoring non-absolute filename: > Missing separate debuginfo for linux-vdso.so.1 > Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/2b/fef7432912bcc87752ef9e66b1ddb71d7485f5 > Core was generated by `sleep 1h'. > Program terminated with signal SIGSEGV, Segmentation fault. > #0 0x00007f3fd8bd6870 in __nanosleep_nocancel () at ../sysdeps/unix/syscall-template.S:84 > 84 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS) > (gdb) bt > #0 0x00007f3fd8bd6870 in __nanosleep_nocancel () at ../sysdeps/unix/syscall-template.S:84 > #1 0x000055f9f5bf829f in rpl_nanosleep (requested_delay=requested_delay@entry=0x7ffe1323cb80, > remaining_delay=remaining_delay@entry=0x0) at lib/nanosleep.c:85 > #2 0x000055f9f5bf8100 in xnanosleep (seconds=) at lib/xnanosleep.c:51 > #3 0x000055f9f5bf5a1d in main (argc=, argv=) at src/sleep.c:145 > (gdb) q