All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Quentin Godfroy <godfroy@clipper.ens.fr>
Cc: linux-kernel@vger.kernel.org,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	"David A. Madore" <David.Madore@ens.fr>,
	"Eric W. Biederman" <ebiederm@xmission.com>
Subject: Re: patch: VFS: fix passing of AT_PHDR value in auxv to ELF interpreter
Date: Fri, 04 May 2007 21:24:05 -0700	[thread overview]
Message-ID: <463C06E5.8050201@goop.org> (raw)
In-Reply-To: <20070505032348.GA30453@goelette.ens.fr>

Quentin Godfroy wrote:
>> Won't this break with ET_DYN executables?  And besides, isn't this the
>> same thing?                                                           
>>     
>
> Indeed, I haven't seen that. For ET_DYN executables, it could be done a
> thing like load_addr+elf_ppnt->p_vaddr (in the function that creates the
> auxv, as ity has access to the elf header), and for ET_EXEC do what I
> propose. I think this is trivial to do. I'll do it as soon as I come back
> in front of my machine.
>   

I don't think you need to special-case it.  You can compute the offset
between the linked address and the load address (first
PT_LOAD[0]->p_vaddr - load_addr) and use that to offset all the other
addresses.


> I don't understand. Yes it is what it is supposed to be, and the kernel
> is supposed to give the vaddr of the phdr table to the interpreter and
> not load addr + offset of phdr in file, which is sometimes wrong.
>   

How can it be wrong?  Does the PT_PHDR point to a different array of
Phdr entries?

    J

  reply	other threads:[~2007-05-05  4:24 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-04 14:09 patch: VFS: fix passing of AT_PHDR value in auxv to ELF interpreter Quentin Godfroy
2007-05-04 23:22 ` Andrew Morton
2007-05-05  3:34   ` Quentin Godfroy
2007-05-05  4:27     ` Andrew Morton
2007-05-04 23:31 ` Jeremy Fitzhardinge
2007-05-05  3:23   ` Quentin Godfroy
2007-05-05  4:24     ` Jeremy Fitzhardinge [this message]
2007-05-06 23:43       ` Quentin Godfroy
2007-05-07 17:47 ` Quentin Godfroy
2007-05-07 18:11   ` Quentin Godfroy

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=463C06E5.8050201@goop.org \
    --to=jeremy@goop.org \
    --cc=David.Madore@ens.fr \
    --cc=ebiederm@xmission.com \
    --cc=godfroy@clipper.ens.fr \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.