From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22873 invoked by alias); 20 Sep 2014 21:30: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 22857 invoked by uid 89); 20 Sep 2014 21:30:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.3 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Sat, 20 Sep 2014 21:30:41 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s8KLUbRF015047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 20 Sep 2014 17:30:38 -0400 Received: from host2.jankratochvil.net (ovpn-116-67.ams2.redhat.com [10.36.116.67]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s8KLUYKt003116 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Sat, 20 Sep 2014 17:30:36 -0400 Date: Sat, 20 Sep 2014 21:30:00 -0000 From: Jan Kratochvil To: Pedro Alves Cc: Doug Evans , "gdb-patches@sourceware.org" Subject: Re: time to workaround libc/13097 in fsf gdb? Message-ID: <20140920213033.GA6255@host2.jankratochvil.net> References: <5411CFAE.7040805@redhat.com> <20140912115452.GA5626@host2.jankratochvil.net> <5412E3AC.80203@redhat.com> <20140912123320.GA8704@host2.jankratochvil.net> <5412EB1F.40309@redhat.com> <20140917201049.GA22880@host2.jankratochvil.net> <541C3FCF.4000400@redhat.com> <541C409E.6010408@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <541C409E.6010408@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2014-09/txt/msg00648.txt.bz2 On Fri, 19 Sep 2014 16:41:34 +0200, Pedro Alves wrote: > Here it is. WDYT? [...] > --- a/gdb/solib-svr4.c > +++ b/gdb/solib-svr4.c [...] > @@ -1478,6 +1479,42 @@ svr4_current_sos (void) > return svr4_current_sos_direct (info); > } > > +/* Implement the "current_sos" target_so_ops method. */ > + > +static struct so_list * > +svr4_current_sos (void) > +{ > + struct so_list *so_head = svr4_current_sos_1 (); > + struct objfile *objfile; > + struct obj_section *osect; > + CORE_ADDR vsyscall_addr = gdbarch_vsyscall_address (target_gdbarch ()); > + > + /* Filter out the vDSO module, if present. Its symbol file would > + not be found on disk. The vDSO/vsyscall's OBJFILE is instead > + managed by symfile-mem.c:add_vsyscall_page. */ > + if (vsyscall_addr != 0) > + { > + struct so_list **sop; > + > + sop = &so_head; > + while (*sop != NULL) > + { > + struct so_list *so = *sop; > + > + if (so->lm_info->l_addr_inferior == vsyscall_addr) This won't work as l_addr_inferior (and also l_addr) do not necessarily represent the real starting address of the ELF if the ELF itself is "prelinked". For some reason vDSOs on some kernels look like prelinked. kernel-3.16.2-200.fc20.x86_64 appears sane, vDSO is 0-based. But for example kernel-2.6.32-220.el6.x86_64 is "prelinked", see below. That's the pain of solib-svr4.c which is OS-agnostic and so it cannot find out start of the ELF file just from link map. gdbserver can find it as it can depend on /proc/PID/{s,}maps as its linux-low.c is Linux-specific. That was implemented in unfinished/pending: [PATCH v5 0/8] Validate binary before use Message-ID: <20140319223004.14668.20989.stgit@host1.jankratochvil.net> Thanks, Jan kernel-2.6.32-220.el6.x86_64 (gdb) p *_r_debug.r_map.l_next $4 = {l_addr = 140737363566592, l_name = 0x3deba1ade4 "", l_ld = 0x7ffff7ffe580, l_next = 0x7ffff7ffd658, l_prev = 0x3debc21188} (gdb) p/x *_r_debug.r_map.l_next $5 = {l_addr = 0x7ffff88fe000, l_name = 0x3deba1ade4, l_ld = 0x7ffff7ffe580, l_next = 0x7ffff7ffd658, l_prev = 0x3debc21188} # (gdb) p/x *new.lm_info # $5 = {l_addr = 0x0, l_addr_inferior = 0x7ffff88fe000, l_addr_p = 0x0, lm_addr = 0x3debc21718, l_ld = 0x7ffff7ffe580, l_next = 0x7ffff7ffd658, l_prev = 0x3debc21188, l_name = 0x3deba1ade4} (gdb) info auxv 33 AT_SYSINFO_EHDR System-supplied DSO's ELF header 0x7ffff7ffe000 (gdb) info proc mappings 0x7ffff7ffe000 0x7ffff7fff000 0x1000 0 [vdso] (gdb) dump memory vdso.bin 0x7ffff7ffe000 0x7ffff7fff000 # readelf -Wa vdso.bin [...] Entry point address: 0xffffffffff700700 [...] Section Headers: [Nr] Name Type Address Off Size ES Flg Lk Inf Al [ 0] NULL 0000000000000000 000000 000000 00 0 0 0 [ 1] .hash HASH ffffffffff700120 000120 000038 04 A 2 0 8 [ 2] .dynsym DYNSYM ffffffffff700158 000158 0000d8 18 A 3 2 8 [...] [ 9] .dynamic DYNAMIC ffffffffff700580 000580 0000f0 10 WA 3 0 8