From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14945 invoked by alias); 9 Mar 2014 18:58:59 -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 14928 invoked by uid 89); 9 Mar 2014 18:58:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.1 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 09 Mar 2014 18:58:57 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s29Iw7Ux002546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 9 Mar 2014 14:58:07 -0400 Received: from host2.jankratochvil.net (ovpn-116-86.ams2.redhat.com [10.36.116.86]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s29Iw4OU031974 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 9 Mar 2014 14:58:06 -0400 Date: Sun, 09 Mar 2014 18:58:00 -0000 From: Jan Kratochvil To: Eli Zaretskii Cc: gdb-patches@sourceware.org, ARistovski@qnx.com Subject: Re: [PATCH v4 0/8] Validate binary before use Message-ID: <20140309185803.GA24593@host2.jankratochvil.net> References: <20140302195248.10290.22958.stgit@host1.jankratochvil.net> <837g8ctjkj.fsf@gnu.org> <20140308195717.GA2333@host2.jankratochvil.net> <837g83pb47.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <837g83pb47.fsf@gnu.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2014-03/txt/msg00220.txt.bz2 On Sun, 09 Mar 2014 17:53:12 +0100, Eli Zaretskii wrote: > I suggest to say that between these two sentences. Something like > > @value{GDBN} expects the build-ids of each shared library and its > corresponding symbol file to match. If they don't match, then by > default @value{GDBN} will ... > > A question: does "match" here means the build-ids should be identical? > If so, perhaps use "identical" or "equal" instead of "match". Yes, identical or equal is correct. > > +while printing: > > + > > +@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. > 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. Thanks, Jan