From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26043 invoked by alias); 19 Mar 2014 12:03:48 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 26022 invoked by uid 89); 19 Mar 2014 12:03:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients 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; Wed, 19 Mar 2014 12:03:46 +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 s2JC3hsg020994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Mar 2014 08:03:43 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s2JC3eB3030004; Wed, 19 Mar 2014 08:03:41 -0400 Message-ID: <5329879C.6070805@redhat.com> Date: Wed, 19 Mar 2014 12:03:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Metzger, Markus T" , Mark Wielaard , Cary Coutant , Doug Evans , "gdb@sourceware.org" , "binutils@sourceware.org" Subject: Re: vdso handling References: <20140313010147.GZ26922@bubble.grove.modra.org> <1394704336.11818.115.camel@bordewijk.wildebeest.org> <20140313130322.GA3384@bubble.grove.modra.org> <5321C7C8.6000707@redhat.com> <5321C8FA.40708@gmail.com> <5321CE1A.20509@redhat.com> <20140313235347.GD3384@bubble.grove.modra.org> <20140318230939.GA9145@bubble.grove.modra.org> In-Reply-To: <20140318230939.GA9145@bubble.grove.modra.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-03/txt/msg00053.txt.bz2 On 03/18/2014 11:09 PM, Alan Modra wrote: > I don't think this is a good idea. If/when bfd_from_remote_memory is > used for something other than the linux kernel vdso, we can't assume > the section headers are loaded. I wonder what use cases are these though. It'd be odd to me to load the elf headers, but not all that the headers point at. Sounds like we should just make that a requirement? I looked at the history of this whole code, and here's what I found. Roland originally added this bfd function for reading the Linux vsyscall dso, in 8d6337fe: https://sourceware.org/ml/binutils/2003-05/msg00542.html As far as I can judge from http://lwn.net/Articles/30258/ , and from looking at the early days of the vsyscall dso in the Linux tree, it looks like the vsyscall dso was always included complete in memory (e.g., at v2.6.12-rc2, the initial git import): ... /* 32bit VDSOs mapped into user space. */ asm(".section \".init.data\",\"aw\"\n" "syscall32_syscall:\n" ".incbin \"arch/x86_64/ia32/vsyscall-syscall.so\"\n" "syscall32_syscall_end:\n" "syscall32_sysenter:\n" ".incbin \"arch/x86_64/ia32/vsyscall-sysenter.so\"\n" "syscall32_sysenter_end:\n" ".previous"); ... # The DSO images are built using a special linker script quiet_cmd_syscall = SYSCALL $@ cmd_syscall = $(CC) -m32 -nostdlib -shared -s \ -Wl,-soname=linux-gate.so.1 -o $@ \ -Wl,-T,$(filter-out FORCE,$^) ... I found no sign of strip or of any special elf munging. GDB only uses bfd_elf_bfd_from_remote_memory for the vdso, and for "add-symbol-file-from-memory". Roland himself added the "add-symbol-file-from-memory" command (5417f6dc) to GDB too, at: https://www.sourceware.org/ml/gdb-patches/2003-10/msg00045.html "This command may not really be worth having, but it serves to exercise the underlying function symbol_file_add_from_memory. That function does the work of reading symbols and unwind info from the Linux vsyscall DSO." -- Pedro Alves