From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25636 invoked by alias); 5 Apr 2013 11:47:44 -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 25624 invoked by uid 89); 5 Apr 2013 11:47:44 -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,TW_BJ 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; Fri, 05 Apr 2013 11:47:40 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r35Bla4q025965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 5 Apr 2013 07:47:36 -0400 Received: from host2.jankratochvil.net (ovpn-116-44.ams2.redhat.com [10.36.116.44]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r35BlWYl027426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 5 Apr 2013 07:47:35 -0400 Date: Fri, 05 Apr 2013 13:03:00 -0000 From: Jan Kratochvil To: Aleksandar Ristovski Cc: gdb-patches@sourceware.org Subject: Re: [patch] validate binary before use Message-ID: <20130405114732.GA11684@host2.jankratochvil.net> References: <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> <20130404081302.GA4099@host2.jankratochvil.net> <515D7A09.5010305@qnx.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <515D7A09.5010305@qnx.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2013-04/txt/msg00117.txt.bz2 On Thu, 04 Apr 2013 15:03:05 +0200, Aleksandar Ristovski wrote: > The problem is, we could 'remember' build-id that is garbage. Where/how? In gdbserver mode gdbserver sends really the build-id of target library. Therefore at GDB so_list->build_id - if set - is also always right (for the target side). GDB then uses elf_tdata (so->abfd)->build_id for the comparison which is also always right on the GDB side. In solib-svr4 mode GDB uses target_read_memory for an address found from the symbol file. This may read a garbage but that garbage is never stored anywhere, it is only local variable in svr4_validate_build_id. It compares it with elf_tdata (so->abfd)->build_id which is always right for the symbol file. > I will > add checking for GNU\0 and note type, and then the likelihood that > somewhat random memory will match namesz, name and type will be very > low (though the likelihood has nothing to do with the 160 bits of > build-id; build-id is not necessarily 160 bits either). I do not understand this paragraph after my reply above. > The rest is about design and duplicated functionality. The > functionality of gdbserver where it fetches the list is exactly the > same what -nat can do; I was talking about linux-nat to differentiate it from gdbserver. But in fact the non-gdbserver (local) patchset part is in solib-svr4.c, not linux-nat.c. Only that commonly when one uses the local part of solib-svr4.c one is using linux-nat.c that time - but one could be using for example sparc-sol2-nat.c instead. As discussed before solib-svr4.c is not Linux-specific, therefore it does not and cannot read /proc/PID/maps. Therefore it cannot find the ELF header without getting a help from the symbol file (which will give the address difference between ELF header and DYNAMIC segment which we know from l_ld). At least I have never found a way how to reliably find the ELF header from link_map entry without having an associated symbol file. This is why gdbserver (using linux-low.c which IS Linux specific) situation is very different from the non-gdbserver local (using solib-svr4.c which is OS-independent) situation. Sure one could make a Linux-specific local solib-*.c backend but the current plan is to drop all (in reality just some) *-nat.c files in the favor of always using gdbserver. > in fact this could be the same code; Really could not, see above. The local solib-svr4.c mode should not exist but it unfortunately still needs to be kept live as gdbserver is not fully feature-by-feature matching linux-nat.c: http://sourceware.org/gdb/wiki/LocalRemoteFeatureParity > Not to be neglected is that by doing so, it would be possible to > look for the debug binary directly, by using build-id instead of > opening objfile and then looking for separate_debug_fie. Unfortunately could not. Thanks, Jan