Re: dl_iterate_phdr(3) needs clarification

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:

quoted

Hi Yubin,

On 15 September 2017 at 10:44, Yubin Ruan [off-list ref] wrote:

quoted

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.)

quoted

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