From: Alan Modra <amodra@gmail.com>
To: "Metzger, Markus T" <markus.t.metzger@intel.com>
Cc: Pedro Alves <palves@redhat.com>, Mark Wielaard <mjw@redhat.com>,
Cary Coutant <ccoutant@google.com>, Doug Evans <dje@google.com>,
"gdb@sourceware.org" <gdb@sourceware.org>,
"binutils@sourceware.org" <binutils@sourceware.org>
Subject: Re: vdso handling
Date: Tue, 18 Mar 2014 23:10:00 -0000 [thread overview]
Message-ID: <20140318230939.GA9145@bubble.grove.modra.org> (raw)
In-Reply-To: <A78C989F6D9628469189715575E55B230AAB6B17@IRSMSX103.ger.corp.intel.com>
On Tue, Mar 18, 2014 at 03:09:58PM +0000, Metzger, Markus T wrote:
> diff --git a/bfd/elfcode.h b/bfd/elfcode.h
> index 20101be..601d7ea 100644
> --- a/bfd/elfcode.h
> +++ b/bfd/elfcode.h
> @@ -1616,7 +1616,7 @@ NAME(_bfd_elf,bfd_from_remote_memory)
> bfd_byte *contents;
> int err;
> unsigned int i;
> - bfd_vma loadbase;
> + bfd_vma loadbase, shdr_begin, shdr_end;
> bfd_boolean loadbase_set;
>
> /* Read in the ELF header in external format. */
> @@ -1728,20 +1728,16 @@ NAME(_bfd_elf,bfd_from_remote_memory)
> }
>
> /* Trim the last segment so we don't bother with zeros in the last page
> - that are off the end of the file. However, if the extra bit in that
> - page includes the section headers, keep them. */
> - if ((bfd_vma) contents_size > last_phdr->p_offset + last_phdr->p_filesz
> - && (bfd_vma) contents_size >= (i_ehdr.e_shoff
> - + i_ehdr.e_shnum * i_ehdr.e_shentsize))
> - {
> - contents_size = last_phdr->p_offset + last_phdr->p_filesz;
> - if ((bfd_vma) contents_size < (i_ehdr.e_shoff
> - + i_ehdr.e_shnum * i_ehdr.e_shentsize))
> - contents_size = i_ehdr.e_shoff + i_ehdr.e_shnum * i_ehdr.e_shentsize;
> - }
> - else
> + that are off the end of the file. */
> + if ((bfd_vma) contents_size > last_phdr->p_offset + last_phdr->p_filesz)
> contents_size = last_phdr->p_offset + last_phdr->p_filesz;
>
> + /* Keep the section headers. */
> + shdr_begin = i_ehdr.e_shoff;
> + shdr_end = shdr_begin + i_ehdr.e_shnum * i_ehdr.e_shentsize;
> + if (shdr_end > (bfd_vma) contents_size)
> + contents_size = shdr_end;
> +
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. The original code made the assumption
that the highest address loaded from a PT_LOAD header was rounded up
to a page, and that the page size could be inferred from p_align.
Here:
segment_end = (i_phdrs[i].p_offset + i_phdrs[i].p_filesz
+ i_phdrs[i].p_align - 1) & -i_phdrs[i].p_align;
if (segment_end > (bfd_vma) contents_size)
contents_size = segment_end;
Now, p_align is generally set from the page size if using GNU ld, but
I'm wondering if your vdso somehow doesn't have that property. Can
you show us your vdso readelf -e output? If p_align isn't set to a
page, then the change in heuristic I envision is to make use of
elf_backend_data maxpagesize to figure out which parts of the image
might be loaded. If that isn't enough then perhaps we should add
another parameter to bfd_from_remote_memory to allow its caller to
specify the end of the image.
> Would it be OK to send this patch as part of a GDB patch series with
> binutils-patches and you CC'ed? Or do you want a separate patch
> only to binutils-patches?
I don't mind either way. This part of bfd belongs to gdb, so gdb
maintainers really have the final say on patch approval. I'm just
someone who happened to become interested in the problem..
--
Alan Modra
Australia Development Lab, IBM
next prev parent reply other threads:[~2014-03-18 23:10 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-10 13:05 Metzger, Markus T
2014-03-12 7:17 ` Alan Modra
2014-03-12 11:31 ` Mike Frysinger
2014-03-12 17:34 ` Doug Evans
2014-03-12 20:23 ` Cary Coutant
2014-03-13 1:01 ` Alan Modra
2014-03-13 8:25 ` Metzger, Markus T
2014-03-13 9:48 ` Metzger, Markus T
2014-03-13 10:07 ` Pedro Alves
2014-03-13 10:46 ` Pedro Alves
2014-06-01 20:32 ` Samuel Bronson
2014-06-06 12:45 ` Pedro Alves
2014-03-13 13:13 ` Alan Modra
2014-03-13 9:52 ` Mark Wielaard
2014-03-13 13:03 ` Alan Modra
2014-03-13 14:38 ` Mark Wielaard
2014-03-13 14:59 ` Pedro Alves
2014-03-13 15:04 ` Pedro Alves
2014-03-13 15:26 ` Pedro Alves
2014-03-13 23:53 ` Alan Modra
2014-03-18 15:14 ` Metzger, Markus T
2014-03-18 23:10 ` Alan Modra [this message]
2014-03-19 8:11 ` Metzger, Markus T
2014-03-19 8:31 ` Metzger, Markus T
2014-03-19 12:04 ` Pedro Alves
2014-03-20 2:00 ` Alan Modra
2014-03-21 15:55 ` Pedro Alves
2014-03-26 9:32 ` Metzger, Markus T
2014-03-19 12:03 ` Pedro Alves
2014-03-20 1:33 ` Alan Modra
2014-03-21 8:10 ` Metzger, Markus T
2014-03-21 15:48 ` Pedro Alves
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140318230939.GA9145@bubble.grove.modra.org \
--to=amodra@gmail.com \
--cc=binutils@sourceware.org \
--cc=ccoutant@google.com \
--cc=dje@google.com \
--cc=gdb@sourceware.org \
--cc=markus.t.metzger@intel.com \
--cc=mjw@redhat.com \
--cc=palves@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox