From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10990 invoked by alias); 5 Apr 2013 13:06:46 -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 10971 invoked by uid 89); 5 Apr 2013 13:06:46 -0000 X-Spam-SWARE-Status: No, score=-4.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,TW_BJ autolearn=ham version=3.3.1 Received: from na3sys009aog104.obsmtp.com (HELO na3sys009aog104.obsmtp.com) (74.125.149.73) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Fri, 05 Apr 2013 13:06:40 +0000 Received: from mx20.qnx.com ([72.1.200.103]) (using TLSv1) by na3sys009aob104.postini.com ([74.125.148.12]) with SMTP ID DSNKUV7MXeTyfkKpSHSW4DjjAX+T0i18E8zV@postini.com; Fri, 05 Apr 2013 06:06:39 PDT Received: by mx20.qnx.com (Postfix, from userid 500) id 5CB3420E53; Fri, 5 Apr 2013 09:06:37 -0400 (EDT) Received: from exhts.ott.qnx.com (exch2 [10.222.2.136]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx20.qnx.com (Postfix) with ESMTPS id 0E7A520E1F; Fri, 5 Apr 2013 09:06:37 -0400 (EDT) Received: from [10.222.96.215] (10.222.2.5) by EXCH2.ott.qnx.com (10.222.2.136) with Microsoft SMTP Server (TLS) id 14.2.318.4; Fri, 5 Apr 2013 09:06:36 -0400 Message-ID: <515ECC5C.7040609@qnx.com> Date: Fri, 05 Apr 2013 16:08:00 -0000 From: Aleksandar Ristovski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Jan Kratochvil CC: Subject: Re: [patch] validate binary before use 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> <20130405114732.GA11684@host2.jankratochvil.net> In-Reply-To: <20130405114732.GA11684@host2.jankratochvil.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2013-04/txt/msg00125.txt.bz2 On 13-04-05 07:47 AM, Jan Kratochvil wrote: > 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. Correct. > > 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. It is stored in the latest patch, in build-id. > > >> 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. See my comment 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. What I am suggesting is that linux-nat (and any other *-nat) should implement TARGET_OBJECT_LIBRARIES_SVR4. > > 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. Exactly, see above. > > 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 I don't think you are following me, but hopefully my comments above clarify it. > > >> 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 >