mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@aerifal.cx>
To: musl@lists.openwall.com
Subject: Re: PATCH: dl_iterate_phdr()
Date: Thu, 11 Oct 2012 19:42:55 -0400	[thread overview]
Message-ID: <20121011234255.GB254@brightrain.aerifal.cx> (raw)
In-Reply-To: <CAFXnQt4wBoJE4eZzVHChwpEbrzS7fm9U8VL1M02Opem7vn1fMw@mail.gmail.com>

On Thu, Oct 11, 2012 at 09:29:28AM -0500, Alex Caudill wrote:
> Hi!
> 
> With a little help on IRC I hacked together a basic version of
> dl_iterate_phdr(), which I dropped into src/ldso/dynlink.c in my tree.
> This introduces a new include file: <link.h>
> 
> Line #9 of dl_iterate_phdr.c throws a warning that I'm not sure how to silence.
> 
> I've attached both, and a test program. No copyright.
> 
> Thanks!

> int dl_iterate_phdr(int(*callback)(struct dl_phdr_info *info, size_t size, void *data), void *data)
> {   
>     struct dso *current;
>     Ehdr *ehdr;
>     struct dl_phdr_info info;
>     int ret = 0;
>     for(current = head; current; current = current->next) {
>         ehdr = (Ehdr *)current->map;
>         info.dlpi_addr = (ehdr->e_type == ET_EXEC) ? 0 : current->map;

This is wrong; it should be current->base. See the man page:

    The dlpi_addr field indicates the base address of the shared
    object (i.e., the difference between the virtual memory address of
    the shared object and the offset of that object in the file from
    which it was loaded).

>         info.dlpi_name = current->shortname;

This too:

    The dlpi_name field is a null-terminated string giving the
    pathname from which the shared object was loaded.

i.e. it needs to be using name, not shortname. The only place
shortname is to use is to match libraries loaded by name without a
pathname provided. It's NULL for libraries explicitly loaded by
pathname.

>         info.dlpi_phdr = (Phdr *)(current->map + ehdr->e_phoff);

It might make more sense to save the phdr address during library
loading instead of reading the Ehdr again, especially since there's no
fundamental guarantee the Ehdr is available anymore. (It could be in
an unmapped page at the beginning of the library prior to the mapped
portion. This usage is ugly and may not even work with musl right now,
but there's no reason to add more gratuitous reasons it should fail.)

>         info.dlpi_phnum = ehdr->e_phnum;
> 
>         ret = (callback)(&info, sizeof (info), data);
>         if (ret != 0)
>             break;
>     }
>     return ret;
> }

> #ifndef LINK_H
> #define LINK_H

Missing underscore. Not absolutely essential since this is a
nonstandard header, but it should be there.

> 
> #include <elf.h>
> 
> #define __NEED_size_t
> #include <bits/alltypes.h>
> 
> #ifdef _LP64

Should use UINTPTR_MAX.

> #define ElfW(type)      Elf64_ ## type
> #else   
> #define ElfW(type)      Elf32_ ## type
> #endif
> 
> struct dl_phdr_info {
>     ElfW(Addr)              dlpi_addr;  
>     const char              *dlpi_name;
>     const ElfW(Phdr)        *dlpi_phdr;
>     ElfW(Half)              dlpi_phnum;
> };

We need to provide the "ElfW" macro since calling code might use it,
but I'd rather it not be used internally. Just use the correct types
(e.g. uintptr_t or size_t, etc.).

Otherwise, looks okay!

Rich


  reply	other threads:[~2012-10-11 23:42 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-11 14:29 Alex Caudill
2012-10-11 23:42 ` Rich Felker [this message]
2012-10-12  0:00   ` Rich Felker
2012-10-12 13:28     ` Alex Caudill
2012-10-12 15:43       ` Rich Felker
2012-10-13  1:04         ` Alex Caudill
2012-10-13  1:24           ` Alex Caudill
2012-10-13  1:31             ` Rich Felker
2012-10-15  3:30             ` Rich Felker
2012-10-15  4:47               ` Alex Caudill
2012-10-15 12:41                 ` Rich Felker
2012-10-18 20:45                 ` Rich Felker
2012-10-31 18:35                   ` Alex Caudill
2012-11-01  1:33                     ` Rich Felker

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=20121011234255.GB254@brightrain.aerifal.cx \
    --to=dalias@aerifal.cx \
    --cc=musl@lists.openwall.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.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).