From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25370 invoked by alias); 4 Apr 2013 08:13:16 -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 25360 invoked by uid 89); 4 Apr 2013 08:13:15 -0000 X-Spam-SWARE-Status: No, score=-7.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.1 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Thu, 04 Apr 2013 08:13:10 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r348D7IA007456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Apr 2013 04:13:07 -0400 Received: from host2.jankratochvil.net (ovpn-116-44.ams2.redhat.com [10.36.116.44]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r348D3Tj013014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 4 Apr 2013 04:13:06 -0400 Date: Thu, 04 Apr 2013 13:30:00 -0000 From: Jan Kratochvil To: Aleksandar Ristovski Cc: gdb-patches@sourceware.org Subject: Re: [patch] validate binary before use Message-ID: <20130404081302.GA4099@host2.jankratochvil.net> References: <510A7EB0.90702@qnx.com> <51278A2A.9000802@qnx.com> <512E42D1.3040101@qnx.com> <514C58B2.6090701@qnx.com> <20130328183727.GA14798@host2.jankratochvil.net> <515B0632.1040502@qnx.com> <20130402165306.GA9479@host2.jankratochvil.net> <515B12D1.7050505@qnx.com> <20130403180917.GA6102@host2.jankratochvil.net> <515CDF7F.5020403@qnx.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <515CDF7F.5020403@qnx.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2013-04/txt/msg00099.txt.bz2 On Thu, 04 Apr 2013 04:03:43 +0200, Aleksandar Ristovski wrote: > Actually, as I think about this more, we can not use section from > possibly unrelated bfd to read build-id in native debugging case. At > a minimum, we can not store such build-id as abfd may not even > relate to what's in target's memory. Why? If the target shared library does not match then GDB will read some random memory. The target shared library may not even have any build-id. As the build-id has 160 bits there is 1:2^160 probability of a false positive, that is safe enough. > The chunk of code that is in svr4_relocate_section_addresses in the you probably mean solib_map_sections > latest version of the patch needs to go back to svr4_validate, and > not store build-id. I do not understand this whole mail, it would be best to provide a countercase where the current patchset does not behave correctly. Thanks, Jan