This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFE: dl_iterate_phdr, r_debug.r_brk usability for introspection


On 09/23/2015 05:24 PM, Rich Felker wrote:
On Wed, Sep 23, 2015 at 01:33:04PM -0700, Roland McGrath wrote:
   [snip]
while the glibc definition reads:

	struct dl_phdr_info
	  {
	    ElfW(Addr) dlpi_addr;
	    const char *dlpi_name;
	    const ElfW(Phdr) *dlpi_phdr;
	    ElfW(Half) dlpi_phnum;

	    /* Note: Following members were introduced 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.  */

	    /* Incremented when a new object may have been added.  */
	    __extension__ unsigned long long int dlpi_adds;
	    /* Incremented when an object may have been removed.  */
	    __extension__ unsigned long long int dlpi_subs;

	    /* If there is a PT_TLS segment, its module ID as used in
	       TLS relocations, else zero.  */
	    size_t dlpi_tls_modid;

	    /* 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.  */
	    void *dlpi_tls_data;
	  };

I think I invented dlpi_tls_{modid,data} in commit
d78efd9f369a8fc46229fc9224e10e3781eecc43 (2006-02-28 in ChangeLog.16).

dlip_{adds,subs} were added in commit bed12f78fab86b2349cab6e7f4c0e46bde5e9711
(2004-01-23 in ChangeLog.14).

I suspect all of that was before any BSD had dl_iterate_phdr.

So, I guess the answer is, "You're welcome."

Oops. Well, a belated thanks! I knew we adopted these fields from
somewhere, and based on the original post to this thread assumed it
couldn't have been glibc.

Thank you, Roland McGrath, for implementing some time ago the functionality
that I requested as part of the callback from dl_iterate_phdr.


So is there any actual change being requested here that's not already
in glibc?

Yes, I still request better usability for dl_iterate_phdr and r_debug.r_brk.

struct dl_phdr_info now has the functionality, but also has
a new usability problem.  Please document that .dlpi_adds and .dlpi_subs
are a pair which must be provided together, and that .dlpi_tls_modid
and .dlpi_tls_data also are a pair which must be provided together.
Otherwise the conscientious, standards-observing programmer must declare
FIVE structures (appending each of .dlpi_adds, .dlpi_subs, .dlpi_tls_modid, and
.dlpi_tls_data cumulatively in turn after .dlpi_phhum), and compare sizeof() of each
struct with the 'size' parameter (2nd parameter) to the (*callback)() function,
in order to determine which additional data members actually are present.
That is poor usability.  It is inconceivable to provide .dlpi_adds without also
providing .dlpi_subs, but the current documentation allows it.  Please don't do that.
[In general I prefer a data member that contains an explicit enumerated literal
constant version number that increments with each batch of added functionality,
but the original interface of the callback function chose the 'size' method instead.]

With regard to r_debug.r_brk, please change ld-linux so that it
initializes .r_brk once, and thereafter makes a call to
(*r_debug.r_brk)(&r_debug, 0ul) instead of its current calls to some
fixed function that is internal to ld-linux (and whose address is written
into .r_brk by ld-linux.)  These current calls notify a debugger about
about calls to dlopen and dlclose, and therefore are related to .dlpi_adds
and .dlpi_subs; but the present implementation does not allow an introspecting
program to perform this monitoring itself without implementing breakpoints.
Implementing the request would enhance the usability for introspecting apps.
Eventually the argument list might be extended to provide a general
notification facility (such as every time that errno is set, or open/close/EOF
occurs, or ...).  This would provide an extremely useful new feature.
The idea is not fully formed, but the second parameter 0ul reserves
the current actual uses.

Thank you for considering these requests for improved usability.






Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]