Re: dl_iterate_phdr(3) needs clarification

Re: dl_iterate_phdr(3) needs clarification

[Michael Kerrisk (man-pages)]

Hi Yubin,

On 15 September 2017 at 10:44, Yubin Ruan <ablacktshirt-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> i,
> I need some clarification on dl_iterate_phdr(3):
>
> it is claimed that the returned "struct dl_phdr_info" argument has the
> following structure:
>
>   struct dl_phdr_info {
>       ElfW(Addr)  dlpi_addr;  /* Base address of object */
>       const char *dlpi_name;  /* (Null-terminated) name of
>                                        object */
>       const ElfW(Phdr) *dlpi_phdr;  /* Pointer to array of
>                                        ELF program headers
>                                        for this object */
>       ElfW(Half)  dlpi_phnum; /* # of items in dlpi_phdr */
>
>       /* The following fields were added in glibc 2.4, after the first
>          version of this structure was available.  Check the size
>          argument passed to the dl_iterate_phdr callback to determine
>          whether or not each later member is available.  */
>
>       unsigned long long int dlpi_adds;
>                       /* Incremented when a new object may
>                          have been added */
>       unsigned long long int dlpi_subs;
>                       /* Incremented when an object may
>                          have been removed */
>       size_t dlpi_tls_modid;
>                       /* If there is a PT_TLS segment, its module
>                          ID as used in TLS relocations, else zero */
>       void  *dlpi_tls_data;
>                       /* The address of the calling thread's instance
>                          of this module's PT_TLS segment, if it has
>                          one and it has been allocated in the calling
>                          thread, otherwise a null pointer */
>   };
>
> and:
>
>   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).  The dlpi_name field is a null-terminated string giving
>   the pathname from which the shared object was loaded.
>
> What does it mean by "the offset of that object in the file from which it was
> loaded"??? For a shared object, can I assume that this value is always 0? And
> in what circumstance will it not be 0?
>
> The same statement has also been seen at the old man page[1], so I guess the
> author

(That would be me.)

> might have done some copy&paste and overlook this detail.

Can I suggest that as a first step to investigating that you modify
the example program in thepage to print out the values of these
fields?

Thanks,

Michael


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: dl_iterate_phdr(3) needs clarification

[Yubin Ruan]

On Fri, Sep 15, 2017 at 10:33:09AM +0200, Michael Kerrisk (man-pages) wrote:
> Hi Yubin,
> 
> On 15 September 2017 at 10:44, Yubin Ruan <ablacktshirt-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > i,
> > I need some clarification on dl_iterate_phdr(3):
> >
> > it is claimed that the returned "struct dl_phdr_info" argument has the
> > following structure:
> >
> >   struct dl_phdr_info {
> >       ElfW(Addr)  dlpi_addr;  /* Base address of object */
> >       const char *dlpi_name;  /* (Null-terminated) name of
> >                                        object */
> >       const ElfW(Phdr) *dlpi_phdr;  /* Pointer to array of
> >                                        ELF program headers
> >                                        for this object */
> >       ElfW(Half)  dlpi_phnum; /* # of items in dlpi_phdr */
> >
> >       /* The following fields were added in glibc 2.4, after the first
> >          version of this structure was available.  Check the size
> >          argument passed to the dl_iterate_phdr callback to determine
> >          whether or not each later member is available.  */
> >
> >       unsigned long long int dlpi_adds;
> >                       /* Incremented when a new object may
> >                          have been added */
> >       unsigned long long int dlpi_subs;
> >                       /* Incremented when an object may
> >                          have been removed */
> >       size_t dlpi_tls_modid;
> >                       /* If there is a PT_TLS segment, its module
> >                          ID as used in TLS relocations, else zero */
> >       void  *dlpi_tls_data;
> >                       /* The address of the calling thread's instance
> >                          of this module's PT_TLS segment, if it has
> >                          one and it has been allocated in the calling
> >                          thread, otherwise a null pointer */
> >   };
> >
> > and:
> >
> >   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).  The dlpi_name field is a null-terminated string giving
> >   the pathname from which the shared object was loaded.
> >
> > What does it mean by "the offset of that object in the file from which it was
> > loaded"??? For a shared object, can I assume that this value is always 0? And
> > in what circumstance will it not be 0?
> >
> > The same statement has also been seen at the old man page[1], so I guess the
> > author
> 
> (That would be me.)
> 
> > might have done some copy&paste and overlook this detail.
> 
> Can I suggest that as a first step to investigating that you modify
> the example program in thepage to print out the values of these
> fields?

Hmm..based on my understanding of the ELF format and linker/loader, that
`p_vaddr' should be 0 for a executable, and should be the runtime address for a
share object. But I have to take some time and look into the source first. If
that is indeed the case, I would suggest some modification to this man page...

Yubin
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: dl_iterate_phdr(3) needs clarification

[Yubin Ruan]

On Sat, Sep 16, 2017 at 08:37:01PM +0800, Yubin Ruan wrote:
> On Fri, Sep 15, 2017 at 10:33:09AM +0200, Michael Kerrisk (man-pages) wrote:
> > Hi Yubin,
> > 
> > On 15 September 2017 at 10:44, Yubin Ruan <ablacktshirt-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > i,
> > > I need some clarification on dl_iterate_phdr(3):
> > >
> > > it is claimed that the returned "struct dl_phdr_info" argument has the
> > > following structure:
> > >
> > >   struct dl_phdr_info {
> > >       ElfW(Addr)  dlpi_addr;  /* Base address of object */
> > >       const char *dlpi_name;  /* (Null-terminated) name of
> > >                                        object */
> > >       const ElfW(Phdr) *dlpi_phdr;  /* Pointer to array of
> > >                                        ELF program headers
> > >                                        for this object */
> > >       ElfW(Half)  dlpi_phnum; /* # of items in dlpi_phdr */
> > >
> > >       /* The following fields were added in glibc 2.4, after the first
> > >          version of this structure was available.  Check the size
> > >          argument passed to the dl_iterate_phdr callback to determine
> > >          whether or not each later member is available.  */
> > >
> > >       unsigned long long int dlpi_adds;
> > >                       /* Incremented when a new object may
> > >                          have been added */
> > >       unsigned long long int dlpi_subs;
> > >                       /* Incremented when an object may
> > >                          have been removed */
> > >       size_t dlpi_tls_modid;
> > >                       /* If there is a PT_TLS segment, its module
> > >                          ID as used in TLS relocations, else zero */
> > >       void  *dlpi_tls_data;
> > >                       /* The address of the calling thread's instance
> > >                          of this module's PT_TLS segment, if it has
> > >                          one and it has been allocated in the calling
> > >                          thread, otherwise a null pointer */
> > >   };
> > >
> > > and:
> > >
> > >   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).  The dlpi_name field is a null-terminated string giving
> > >   the pathname from which the shared object was loaded.
> > >
> > > What does it mean by "the offset of that object in the file from which it was
> > > loaded"??? For a shared object, can I assume that this value is always 0? And
> > > in what circumstance will it not be 0?
> > >
> > > The same statement has also been seen at the old man page[1], so I guess the
> > > author
> > 
> > (That would be me.)
> > 
> > > might have done some copy&paste and overlook this detail.
> > 
> > Can I suggest that as a first step to investigating that you modify
> > the example program in thepage to print out the values of these
> > fields?
> 
> Hmm..based on my understanding of the ELF format and linker/loader, that
> `p_vaddr' should be 0 for a executable, and should be the runtime address for a

sorry, with `p_vaddr', I mean `dlpi_addr'.

> share object. But I have to take some time and look into the source first. If
> that is indeed the case, I would suggest some modification to this man page...
> 
> Yubin
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: dl_iterate_phdr(3) needs clarification

[Yubin Ruan]

Hi Michael,

On Fri, Sep 15, 2017 at 10:33:09AM +0200, Michael Kerrisk (man-pages) wrote:
> Hi Yubin,
> 
> On 15 September 2017 at 10:44, Yubin Ruan <ablacktshirt-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > i,
> > I need some clarification on dl_iterate_phdr(3):
> >
> > it is claimed that the returned "struct dl_phdr_info" argument has the
> > following structure:
> >
> >   struct dl_phdr_info {
> >       ElfW(Addr)  dlpi_addr;  /* Base address of object */
> >       const char *dlpi_name;  /* (Null-terminated) name of
> >                                        object */
> >       const ElfW(Phdr) *dlpi_phdr;  /* Pointer to array of
> >                                        ELF program headers
> >                                        for this object */
> >       ElfW(Half)  dlpi_phnum; /* # of items in dlpi_phdr */
> >
> >       /* The following fields were added in glibc 2.4, after the first
> >          version of this structure was available.  Check the size
> >          argument passed to the dl_iterate_phdr callback to determine
> >          whether or not each later member is available.  */
> >
> >       unsigned long long int dlpi_adds;
> >                       /* Incremented when a new object may
> >                          have been added */
> >       unsigned long long int dlpi_subs;
> >                       /* Incremented when an object may
> >                          have been removed */
> >       size_t dlpi_tls_modid;
> >                       /* If there is a PT_TLS segment, its module
> >                          ID as used in TLS relocations, else zero */
> >       void  *dlpi_tls_data;
> >                       /* The address of the calling thread's instance
> >                          of this module's PT_TLS segment, if it has
> >                          one and it has been allocated in the calling
> >                          thread, otherwise a null pointer */
> >   };
> >
> > and:
> >
> >   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).  The dlpi_name field is a null-terminated string giving
> >   the pathname from which the shared object was loaded.
> >
> > What does it mean by "the offset of that object in the file from which it was
> > loaded"??? For a shared object, can I assume that this value is always 0? And
> > in what circumstance will it not be 0?
> >
> > The same statement has also been seen at the old man page[1], so I guess the
> > author
> 
> (That would be me.)
> 
> > might have done some copy&paste and overlook this detail.
> 
> Can I suggest that as a first step to investigating that you modify
> the example program in thepage to print out the values of these
> fields?

After some investigation, I am convinced that `dlpi_addr' is the runtime
address that is mapped after an executable or a shared object is loaded.
So I think the doc should be modify to the following:

    The dlpi_addr field indicates the base address that is mapped at runtime.
    For an executable this field is always 0 and for a shared object it is the
    address where the shared object is mapped. Therefore, the address of any
    loadable segment in the program header array can be calculated as:

        addr == info->dlpi_addr + info->dlpi_phdr[x].p_vaddr

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

Please see the patch below.

I get this info from several places:

    1) some Solaris doc at [1] (oh Solaris again...)
    2) The ELF spec [2]. In section 2 "Program Loading and Dynamic Linking",
    subsection 3, "Dynamic Loading", there is a paragraph above "Figure 2-8"
    which states that virtual address for executable code is the same as it is
    in the program header file of an executable file, while it is unfixed for
    an shared object, which usually contains position independent code (but
    for a shared object, the differences between each segment are always the
    same as in the shared object file). So, if you inspect the on-disk program
    header file with "readelf -l object-name", and obtain those addresses from
    the program in the current man page, you will see that all the things will
    show up as expected. So, `dlpi_addr' has to be the runtime address that is
    mapped.
    3) I have craft a program which is used to get the runtime address of the
    GOT (and successfully modify some of those fields to "change function
    behavior"). That program is based on the assumption that `dlpi_addr' is
    the runtime address that is mapped.

                Yubin

[1]: https://docs.oracle.com/cd/E36784_01/html/E36874/dl-iterate-phdr-3c.html
[2]: http://www.cs.northwestern.edu/~pdinda/icsclass/doc/elf.pdf (note, I
don't know whether this is the latest ELF spec, but I think things won't
change that much)


Signed-off-by: Yubin Ruan <ablacktshirt-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
======
diff --git a/man3/dl_iterate_phdr.3 b/man3/dl_iterate_phdr.3
index b5b75e8..35107da 100644
--- a/man3/dl_iterate_phdr.3
+++ b/man3/dl_iterate_phdr.3
@@ -121,10 +121,9 @@ header files.)
 .PP
 The
 .I 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).
+field indicates the base address that is mapped at runtime.
+For an executable this field is always 0 and for a shared
+object it is the address where the shared object is mapped.
 The
 .I dlpi_name
 field is a null-terminated string giving the pathname
@@ -258,40 +257,40 @@ is the main program.
 .in +4n
 .EX
 $ \fB./a.out\fP
-Name: "" (9 segments)
+Address: (nil), Name: "" (9 segments)
      0: [      0x400040; memsz:    1f8] flags: 0x5; PT_PHDR
      1: [      0x400238; memsz:     1c] flags: 0x4; PT_INTERP
-     2: [      0x400000; memsz:    ac4] flags: 0x5; PT_LOAD
-     3: [      0x600e10; memsz:    240] flags: 0x6; PT_LOAD
+     2: [      0x400000; memsz:    acc] flags: 0x5; PT_LOAD
+     3: [      0x600e10; memsz:    248] flags: 0x6; PT_LOAD
      4: [      0x600e28; memsz:    1d0] flags: 0x6; PT_DYNAMIC
      5: [      0x400254; memsz:     44] flags: 0x4; PT_NOTE
-     6: [      0x400970; memsz:     3c] flags: 0x4; PT_GNU_EH_FRAME
+     6: [      0x40097c; memsz:     3c] flags: 0x4; PT_GNU_EH_FRAME
      7: [         (nil); memsz:      0] flags: 0x6; PT_GNU_STACK
      8: [      0x600e10; memsz:    1f0] flags: 0x4; PT_GNU_RELRO
-Name: "linux-vdso.so.1" (4 segments)
-     0: [0x7ffc6edd1000; memsz:    e89] flags: 0x5; PT_LOAD
-     1: [0x7ffc6edd1360; memsz:    110] flags: 0x4; PT_DYNAMIC
-     2: [0x7ffc6edd17b0; memsz:     3c] flags: 0x4; PT_NOTE
-     3: [0x7ffc6edd17ec; memsz:     3c] flags: 0x4; PT_GNU_EH_FRAME
-Name: "/lib64/libc.so.6" (10 segments)
-     0: [0x7f55712ce040; memsz:    230] flags: 0x5; PT_PHDR
-     1: [0x7f557145b980; memsz:     1c] flags: 0x4; PT_INTERP
-     2: [0x7f55712ce000; memsz: 1b6a5c] flags: 0x5; PT_LOAD
-     3: [0x7f55716857a0; memsz:   9240] flags: 0x6; PT_LOAD
-     4: [0x7f5571688b80; memsz:    1f0] flags: 0x6; PT_DYNAMIC
-     5: [0x7f55712ce270; memsz:     44] flags: 0x4; PT_NOTE
-     6: [0x7f55716857a0; memsz:     78] flags: 0x4; PT_TLS
-     7: [0x7f557145b99c; memsz:   544c] flags: 0x4; PT_GNU_EH_FRAME
-     8: [0x7f55712ce000; memsz:      0] flags: 0x6; PT_GNU_STACK
-     9: [0x7f55716857a0; memsz:   3860] flags: 0x4; PT_GNU_RELRO
-Name: "/lib64/ld-linux-x86-64.so.2" (7 segments)
-     0: [0x7f557168f000; memsz:  20828] flags: 0x5; PT_LOAD
-     1: [0x7f55718afba0; memsz:   15a8] flags: 0x6; PT_LOAD
-     2: [0x7f55718afe10; memsz:    190] flags: 0x6; PT_DYNAMIC
-     3: [0x7f557168f1c8; memsz:     24] flags: 0x4; PT_NOTE
-     4: [0x7f55716acec4; memsz:    604] flags: 0x4; PT_GNU_EH_FRAME
-     5: [0x7f557168f000; memsz:      0] flags: 0x6; PT_GNU_STACK
-     6: [0x7f55718afba0; memsz:    460] flags: 0x4; PT_GNU_RELRO
+Address: 0x7ffdedbe8000, Name: "" (4 segments)
+     0: [0x7ffdedbe8000; memsz:    f29] flags: 0x5; PT_LOAD
+     1: [0x7ffdedbe8360; memsz:    110] flags: 0x4; PT_DYNAMIC
+     2: [0x7ffdedbe87f8; memsz:     3c] flags: 0x4; PT_NOTE
+     3: [0x7ffdedbe8834; memsz:     3c] flags: 0x4; PT_GNU_EH_FRAME
+Address: 0x7fb9a86ca000, Name: "/lib/x86_64-linux-gnu/libc.so.6" (10 segments)
+     0: [0x7fb9a86ca040; memsz:    230] flags: 0x5; PT_PHDR
+     1: [0x7fb9a8860620; memsz:     1c] flags: 0x4; PT_INTERP
+     2: [0x7fb9a86ca000; memsz: 1bfad0] flags: 0x5; PT_LOAD
+     3: [0x7fb9a8a8a7c0; memsz:   91e0] flags: 0x6; PT_LOAD
+     4: [0x7fb9a8a8dba0; memsz:    1e0] flags: 0x6; PT_DYNAMIC
+     5: [0x7fb9a86ca270; memsz:     44] flags: 0x4; PT_NOTE
+     6: [0x7fb9a8a8a7c0; memsz:     78] flags: 0x4; PT_TLS
+     7: [0x7fb9a886063c; memsz:   54bc] flags: 0x4; PT_GNU_EH_FRAME
+     8: [0x7fb9a86ca000; memsz:      0] flags: 0x6; PT_GNU_STACK
+     9: [0x7fb9a8a8a7c0; memsz:   3840] flags: 0x4; PT_GNU_RELRO
+Address: 0x7fb9a8a94000, Name: "/lib64/ld-linux-x86-64.so.2" (7 segments)
+     0: [0x7fb9a8a94000; memsz:  253b8] flags: 0x5; PT_LOAD
+     1: [0x7fb9a8cb9bc0; memsz:   15a8] flags: 0x6; PT_LOAD
+     2: [0x7fb9a8cb9e70; memsz:    170] flags: 0x6; PT_DYNAMIC
+     3: [0x7fb9a8a941c8; memsz:     24] flags: 0x4; PT_NOTE
+     4: [0x7fb9a8ab68e4; memsz:    63c] flags: 0x4; PT_GNU_EH_FRAME
+     5: [0x7fb9a8a94000; memsz:      0] flags: 0x6; PT_GNU_STACK
+     6: [0x7fb9a8cb9bc0; memsz:    440] flags: 0x4; PT_GNU_RELRO
 .EE
 .in
 .PP
@@ -309,8 +308,8 @@ callback(struct dl_phdr_info *info, size_t size, void *data)
     char *type;
     int p_type, j;
 
-    printf("Name: \\"%s\\" (%d segments)\\n", info\->dlpi_name,
-               info\->dlpi_phnum);
+    printf("Address: %p, name: \\"%s\\" (%d segments)\\n",
+           (void *)info\->dlpi_addr, info\->dlpi_name, info\->dlpi_phnum);
 
     for (j = 0; j < info\->dlpi_phnum; j++) {
         p_type = info\->dlpi_phdr[j].p_type;

--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: dl_iterate_phdr(3) needs clarification

[Florian Weimer]

On 09/16/2017 05:00 PM, Yubin Ruan wrote:
> diff --git a/man3/dl_iterate_phdr.3 b/man3/dl_iterate_phdr.3
> index b5b75e8..35107da 100644
> --- a/man3/dl_iterate_phdr.3
> +++ b/man3/dl_iterate_phdr.3
> @@ -121,10 +121,9 @@ header files.)
>   .PP
>   The
>   .I 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).
> +field indicates the base address that is mapped at runtime.
> +For an executable this field is always 0 and for a shared
> +object it is the address where the shared object is mapped.

The part about executables is not true.  The most common case probably 
is PIE executables.  You see this if you compile the modified test 
program with -fpie -pie on a recent enough toolchain.

Thanks,
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: dl_iterate_phdr(3) needs clarification

[Yubin Ruan]

Hi Florian,

On Sat, Sep 16, 2017 at 10:15:19AM +0200, Florian Weimer wrote:
> On 09/16/2017 05:00 PM, Yubin Ruan wrote:
> >diff --git a/man3/dl_iterate_phdr.3 b/man3/dl_iterate_phdr.3
> >index b5b75e8..35107da 100644
> >--- a/man3/dl_iterate_phdr.3
> >+++ b/man3/dl_iterate_phdr.3
> >@@ -121,10 +121,9 @@ header files.)
> >  .PP
> >  The
> >  .I 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).
> >+field indicates the base address that is mapped at runtime.
> >+For an executable this field is always 0 and for a shared
> >+object it is the address where the shared object is mapped.
> 
> The part about executables is not true.  The most common case probably is
> PIE executables.  You see this if you compile the modified test program with
> -fpie -pie on a recent enough toolchain.

-fpie only affect address of PT_LOAD. The one inidcated by `dlpi_addr' is
always 0 for an executable. Yes there is indeed some confusion, see [1].

Yubin

[1]: https://stackoverflow.com/questions/8875876/getting-the-elf-header-of-the-main-executable
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: dl_iterate_phdr(3) needs clarification

[Florian Weimer]

On 09/16/2017 05:28 PM, Yubin Ruan wrote:

>> The part about executables is not true.  The most common case probably is
>> PIE executables.  You see this if you compile the modified test program with
>> -fpie -pie on a recent enough toolchain.
> 
> -fpie only affect address of PT_LOAD. The one inidcated by `dlpi_addr' is
> always 0 for an executable. Yes there is indeed some confusion, see [1].

I get this with your patched example:

Address: 0x156927e000, name: "" (9 segments)

Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: dl_iterate_phdr(3) needs clarification

[Yubin Ruan]

Hi Florian,
sorry for the late reply. This mail got hidden in some secret mailbox and I
didn't discover it. sorry ;-(

On Sat, Sep 16, 2017 at 10:38:44AM +0200, Florian Weimer wrote:
> On 09/16/2017 05:28 PM, Yubin Ruan wrote:
> 
> > > The part about executables is not true.  The most common case probably is
> > > PIE executables.  You see this if you compile the modified test program with
> > > -fpie -pie on a recent enough toolchain.
> > 
> > -fpie only affect address of PT_LOAD. The one inidcated by `dlpi_addr' is
> > always 0 for an executable. Yes there is indeed some confusion, see [1].
> 
> I get this with your patched example:
> 
> Address: 0x156927e000, name: "" (9 segments)

Indeed, this still needs to be investigated some more. I will come back for
this late. Do you have any idea about the wording? I would like to hear your
understanding.

Yubin
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: dl_iterate_phdr(3) needs clarification

[Yubin Ruan]

On Sat, Sep 16, 2017 at 11:00:56PM +0800, Yubin Ruan wrote:
> Hi Michael,
> 
> On Fri, Sep 15, 2017 at 10:33:09AM +0200, Michael Kerrisk (man-pages) wrote:
> > Hi Yubin,
> > 
> > On 15 September 2017 at 10:44, Yubin Ruan <ablacktshirt-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > i,
> > > I need some clarification on dl_iterate_phdr(3):
> > >
> > > it is claimed that the returned "struct dl_phdr_info" argument has the
> > > following structure:
> > >
> > >   struct dl_phdr_info {
> > >       ElfW(Addr)  dlpi_addr;  /* Base address of object */
> > >       const char *dlpi_name;  /* (Null-terminated) name of
> > >                                        object */
> > >       const ElfW(Phdr) *dlpi_phdr;  /* Pointer to array of
> > >                                        ELF program headers
> > >                                        for this object */
> > >       ElfW(Half)  dlpi_phnum; /* # of items in dlpi_phdr */
> > >
> > >       /* The following fields were added in glibc 2.4, after the first
> > >          version of this structure was available.  Check the size
> > >          argument passed to the dl_iterate_phdr callback to determine
> > >          whether or not each later member is available.  */
> > >
> > >       unsigned long long int dlpi_adds;
> > >                       /* Incremented when a new object may
> > >                          have been added */
> > >       unsigned long long int dlpi_subs;
> > >                       /* Incremented when an object may
> > >                          have been removed */
> > >       size_t dlpi_tls_modid;
> > >                       /* If there is a PT_TLS segment, its module
> > >                          ID as used in TLS relocations, else zero */
> > >       void  *dlpi_tls_data;
> > >                       /* The address of the calling thread's instance
> > >                          of this module's PT_TLS segment, if it has
> > >                          one and it has been allocated in the calling
> > >                          thread, otherwise a null pointer */
> > >   };
> > >
> > > and:
> > >
> > >   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).  The dlpi_name field is a null-terminated string giving
> > >   the pathname from which the shared object was loaded.
> > >
> > > What does it mean by "the offset of that object in the file from which it was
> > > loaded"??? For a shared object, can I assume that this value is always 0? And
> > > in what circumstance will it not be 0?
> > >
> > > The same statement has also been seen at the old man page[1], so I guess the
> > > author
> > 
> > (That would be me.)
> > 
> > > might have done some copy&paste and overlook this detail.
> > 
> > Can I suggest that as a first step to investigating that you modify
> > the example program in thepage to print out the values of these
> > fields?
> 
> After some investigation, I am convinced that `dlpi_addr' is the runtime
> address that is mapped after an executable or a shared object is loaded.
> So I think the doc should be modify to the following:
> 
>     The dlpi_addr field indicates the base address that is mapped at runtime.

I saw some discussion on the web[1] and people seem to be confused by the
base address of a shared object/executable and the base address of the first
PT_LOAD segment. So, it would be better to explicitly state "base address of
the shared object/executable" and "base address of the first PT_LOAD
segment"...

Hopefully you can come up with better word ;-)

Yubin
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: dl_iterate_phdr(3) needs clarification

[Yubin Ruan]

On Sat, Sep 16, 2017 at 11:09:02PM +0800, Yubin Ruan wrote:
> On Sat, Sep 16, 2017 at 11:00:56PM +0800, Yubin Ruan wrote:
> > Hi Michael,
> > 
> > On Fri, Sep 15, 2017 at 10:33:09AM +0200, Michael Kerrisk (man-pages) wrote:
> > > Hi Yubin,
> > > 
> > > On 15 September 2017 at 10:44, Yubin Ruan <ablacktshirt-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > > i,
> > > > I need some clarification on dl_iterate_phdr(3):
> > > >
> > > > it is claimed that the returned "struct dl_phdr_info" argument has the
> > > > following structure:
> > > >
> > > >   struct dl_phdr_info {
> > > >       ElfW(Addr)  dlpi_addr;  /* Base address of object */
> > > >       const char *dlpi_name;  /* (Null-terminated) name of
> > > >                                        object */
> > > >       const ElfW(Phdr) *dlpi_phdr;  /* Pointer to array of
> > > >                                        ELF program headers
> > > >                                        for this object */
> > > >       ElfW(Half)  dlpi_phnum; /* # of items in dlpi_phdr */
> > > >
> > > >       /* The following fields were added in glibc 2.4, after the first
> > > >          version of this structure was available.  Check the size
> > > >          argument passed to the dl_iterate_phdr callback to determine
> > > >          whether or not each later member is available.  */
> > > >
> > > >       unsigned long long int dlpi_adds;
> > > >                       /* Incremented when a new object may
> > > >                          have been added */
> > > >       unsigned long long int dlpi_subs;
> > > >                       /* Incremented when an object may
> > > >                          have been removed */
> > > >       size_t dlpi_tls_modid;
> > > >                       /* If there is a PT_TLS segment, its module
> > > >                          ID as used in TLS relocations, else zero */
> > > >       void  *dlpi_tls_data;
> > > >                       /* The address of the calling thread's instance
> > > >                          of this module's PT_TLS segment, if it has
> > > >                          one and it has been allocated in the calling
> > > >                          thread, otherwise a null pointer */
> > > >   };
> > > >
> > > > and:
> > > >
> > > >   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).  The dlpi_name field is a null-terminated string giving
> > > >   the pathname from which the shared object was loaded.
> > > >
> > > > What does it mean by "the offset of that object in the file from which it was
> > > > loaded"??? For a shared object, can I assume that this value is always 0? And
> > > > in what circumstance will it not be 0?
> > > >
> > > > The same statement has also been seen at the old man page[1], so I guess the
> > > > author
> > > 
> > > (That would be me.)
> > > 
> > > > might have done some copy&paste and overlook this detail.
> > > 
> > > Can I suggest that as a first step to investigating that you modify
> > > the example program in thepage to print out the values of these
> > > fields?
> > 
> > After some investigation, I am convinced that `dlpi_addr' is the runtime
> > address that is mapped after an executable or a shared object is loaded.
> > So I think the doc should be modify to the following:
> > 
> >     The dlpi_addr field indicates the base address that is mapped at runtime.
> 
> I saw some discussion on the web[1] and people seem to be confused by the
> base address of a shared object/executable and the base address of the first
> PT_LOAD segment. So, it would be better to explicitly state "base address of
> the shared object/executable" and "base address of the first PT_LOAD
> segment"...

[1]: https://stackoverflow.com/questions/8875876/getting-the-elf-header-of-the-main-executable
 
> Hopefully you can come up with better word ;-)
> 
> Yubin
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html