From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5163 invoked by alias); 24 May 2007 20:39:22 -0000 Received: (qmail 5147 invoked by uid 22791); 24 May 2007 20:39:17 -0000 X-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,DK_POLICY_SIGNSOME,SPF_HELO_PASS,SPF_PASS,TW_DW X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 24 May 2007 20:39:12 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l4OKd9vY012751 for ; Thu, 24 May 2007 16:39:09 -0400 Received: from pobox.toronto.redhat.com (pobox.toronto.redhat.com [172.16.14.4]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l4OKd8oP010045; Thu, 24 May 2007 16:39:08 -0400 Received: from [10.11.14.169] (vpn-14-169.rdu.redhat.com [10.11.14.169]) by pobox.toronto.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id l4OKd7CX023415; Thu, 24 May 2007 16:39:07 -0400 Message-ID: <4655F80E.9010101@redhat.com> Date: Fri, 25 May 2007 16:50:00 -0000 From: Nurdin User-Agent: Thunderbird 1.5.0.10 (X11/20070302) MIME-Version: 1.0 To: Roland McGrath CC: Frysk List Subject: Re: getting vDSO image into libdwfl References: <20070518071438.4FF511F804E@magilla.localdomain> In-Reply-To: <20070518071438.4FF511F804E@magilla.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact frysk-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: frysk-owner@sourceware.org X-SW-Source: 2007-q2/txt/msg00204.txt.bz2 Roland McGrath wrote: > The dwfl_linux_proc_find_elf callback does this as a skeletal example. > It uses this function (see libdwfl/elf-from-memory.c): > > /* Reconstruct an ELF file by reading the segments out of remote memory > based on the ELF file header at EHDR_VMA and the ELF program headers it > points to. If not null, *LOADBASEP is filled in with the difference > between the addresses from which the segments were read, and the > addresses the file headers put them at. > > The function READ_MEMORY is called to copy at least MINREAD and at most > MAXREAD bytes from the remote memory at target address ADDRESS into the > local buffer at DATA; it should return -1 for errors (with code in > `errno'), 0 if it failed to read at least MINREAD bytes due to EOF, or > the number of bytes read if >= MINREAD. ARG is passed through. */ > > Elf * > elf_from_remote_memory (GElf_Addr ehdr_vma, > GElf_Addr *loadbasep, > ssize_t (*read_memory) (void *arg, void *data, > GElf_Addr address, > size_t minread, > size_t maxread), > void *arg) > > This is an internal function not exported in the DSO or declared anywhere. > I wrote it as the necessary and separable component (and analogous to the > BFD function bfd_elf_bfd_from_remote_memory I added for the gdb vDSO > support). I tested it via dwfl_linux_proc_find_elf (-p option to > eu-addr2line et al). (Back then, /proc/PID/mem had not been made so > "secure", so it even worked in eu-foo without ptrace.) I figured the > details of interface to that code and how it integrates with everything > would be ironed out when a real user came along. Now here we are. > > The signature of the read_memory callback is arbitrary. > It just seemed like the roughly appropriate general thing. > It's easy to change. > > This function doesn't really fit with the libelf interfaces. It could be > exposed by libdwfl in some fashion I suppose. I hadn't really figured out > what seemed right, which is why it's as it is. I could just change its > name and signature slightly, and export it from libdwfl. I just exposed this method inside libdwfl.h and I haven't needed to change the read_memory interface at all.