From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10514 invoked by alias); 20 Mar 2014 01:33:16 -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 10492 invoked by uid 89); 20 Mar 2014 01:33:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-pb0-f53.google.com Received: from mail-pb0-f53.google.com (HELO mail-pb0-f53.google.com) (209.85.160.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Thu, 20 Mar 2014 01:33:13 +0000 Received: by mail-pb0-f53.google.com with SMTP id rp16so176392pbb.12 for ; Wed, 19 Mar 2014 18:33:11 -0700 (PDT) X-Received: by 10.69.0.39 with SMTP id av7mr43117645pbd.4.1395279191420; Wed, 19 Mar 2014 18:33:11 -0700 (PDT) Received: from bubble.grove.modra.org ([101.166.26.37]) by mx.google.com with ESMTPSA id qx11sm1395364pab.35.2014.03.19.18.33.08 for (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Mar 2014 18:33:10 -0700 (PDT) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id 264BEEA00D2; Thu, 20 Mar 2014 12:03:05 +1030 (CST) Date: Thu, 20 Mar 2014 01:33:00 -0000 From: Alan Modra To: Pedro Alves Cc: "Metzger, Markus T" , Mark Wielaard , Cary Coutant , Doug Evans , "gdb@sourceware.org" , "binutils@sourceware.org" Subject: Re: vdso handling Message-ID: <20140320013305.GA13347@bubble.grove.modra.org> Mail-Followup-To: Pedro Alves , "Metzger, Markus T" , Mark Wielaard , Cary Coutant , Doug Evans , "gdb@sourceware.org" , "binutils@sourceware.org" 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> <5329879C.6070805@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5329879C.6070805@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2014-03/txt/msg00058.txt.bz2 On Wed, Mar 19, 2014 at 12:03:40PM +0000, Pedro Alves wrote: > 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. Well, no, the section headers are part of the linking view. The ELF file header points at their *file offset*. Thinking it odd that they are not loaded is exactly the same as thinking it odd that .comment is not loaded! > Sounds like we should just make that a requirement? You indeed could make that a requirement, but it'd mean that object files loaded by glibc ld.so would not satisfy the requirement. Taking Markus' vdso as an example, the PT_LOAD header covers file offsets from 0 to 0xffd and page size is 0x1000. If ld.so were loading a similar image, it would just load in 0 to 0xfff (assuming ld.so's dl_pagesize is also 0x1000). The section headers are at file offset 0x10e0 so would miss being loaded. Nor should they be loaded, since they are completely extraneous to executing the image it would be foolish to waste another page to load them. > "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." Heh, OK, so don't let my comments about more general uses of bfd_from_remote_memory get in your way of fixing this problem. Hmm, if you only want to read vdsos then bfd_from_remote_memory is way overengineered. In fact, I think it could disappear entirely. If you can find the extent of the vdso in gdb, then all of the ELF version of bfd_from_remote_memory prior to allocating the bim is unnecessary, because all that code really does is find the extent. So the tail of bfd_from_remote_memory moves to bfd/opncls.c as (totally untested): bfd_boolean bfd_openr_bim (bfd *templ, void *contents, size_t contents_size) { struct bfd_in_memory *bim; bim = (struct bfd_in_memory *) bfd_malloc (sizeof (struct bfd_in_memory)); if (bim == NULL) return NULL; nbfd = _bfd_new_bfd (); if (nbfd == NULL) { free (bim); return NULL; } nbfd->filename = ""; if (templ != NULL) nbfd->xvec = templ->xvec; bim->size = contents_size; bim->buffer = (bfd_byte *) contents; nbfd->iostream = bim; nbfd->flags = BFD_IN_MEMORY; nbfd->iovec = &_bfd_memory_iovec; nbfd->origin = 0; nbfd->direction = read_direction; nbfd->mtime = time (NULL); nbfd->mtime_set = TRUE; return nbfd; } gdb is then responsible for filling in "contents" and determining "contents_size", which presumably can be done in the same way as you did in https://sourceware.org/ml/binutils/2014-03/msg00130.html The loadbase calculation also moves to gdb, which shouldn't be too hard. Note that "templ" above is optional, which allows you to get rid of /* FIXME: cagney/2004-05-06: Should not require an existing BFD when trying to create a run-time BFD of the VSYSCALL -- Alan Modra Australia Development Lab, IBM