From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27103 invoked by alias); 9 Mar 2014 19:19:17 -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 27093 invoked by uid 89); 9 Mar 2014 19:19:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: mtaout22.012.net.il Received: from mtaout22.012.net.il (HELO mtaout22.012.net.il) (80.179.55.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 09 Mar 2014 19:19:14 +0000 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0N2600A00O9EC300@a-mtaout22.012.net.il> for gdb-patches@sourceware.org; Sun, 09 Mar 2014 21:19:12 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N2600AQMOBZA420@a-mtaout22.012.net.il>; Sun, 09 Mar 2014 21:19:12 +0200 (IST) Date: Sun, 09 Mar 2014 19:19:00 -0000 From: Eli Zaretskii Subject: Re: [PATCH v4 0/8] Validate binary before use In-reply-to: <20140309185803.GA24593@host2.jankratochvil.net> To: Jan Kratochvil Cc: gdb-patches@sourceware.org, ARistovski@qnx.com Reply-to: Eli Zaretskii Message-id: <834n37p4dc.fsf@gnu.org> References: <20140302195248.10290.22958.stgit@host1.jankratochvil.net> <837g8ctjkj.fsf@gnu.org> <20140308195717.GA2333@host2.jankratochvil.net> <837g83pb47.fsf@gnu.org> <20140309185803.GA24593@host2.jankratochvil.net> X-IsSubscribed: yes X-SW-Source: 2014-03/txt/msg00221.txt.bz2 > Date: Sun, 9 Mar 2014 19:58:03 +0100 > From: Jan Kratochvil > Cc: gdb-patches@sourceware.org, ARistovski@qnx.com > > > > +@smallexample > > > + Shared object "libfoo.so.1" could not be validated and will be ignored; > > > + or use 'set solib-build-id-force'. > > > +@end smallexample > > > > Hmm... the text says that GDB will ignore symbol files, but the error > > message you cite complains about the shared library, > > "Shared object" is terminology in GDB, it is in fact the symbol file because > GDB never modifies the inferior itself where the real target shared object > exists. > > Just with the build-id comparisons I used "shared library" (as the target > in-memory data) vs. "symbol file" to highlight this difference. Sorry, I don't follow: libfoo.so.1 is a shared library, isn't it? There's no reference in the message to any symbol file, right? > > and doesn't even mention the fact that the problem is a mismatch of the > > 2 build-ids. Why not say explicitly that the build-id of the symbol file > > doesn't match that of the shared library? > > This comes from the API, I can rework the patch. The API currently uses > method "validate" which can validate it in arbitary way. The current only > implmentation in solib-svr4 implements the validation using build-ids but the > error/warning message is currently handled by the caller, not the > build-id-specific implementation in solib-svr4. I think it's fine to leave the validation details unspecified, if you want. But then we shouldn't reveal that its actual implementation is comparing the build-ids. If we want to leave it opaque, let's do it consistently, i.e. both in the warnings printed by GDB and in the manual. OTOH, if we do want to tell that build-ids should be identical, then let's say that in the warning/error messages as well, again for consistency.