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@xxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
