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: [PATCH,resubmit] Add static probes to runtime linker


Gary> +  map_complete:
Gary> +    The linker has finished removing objects into the specified
Gary> +    namespace.  The namespace's r_debug structure is consistent and
Gary> +    may be inspected.

Paul> Typo above: should be unmap_complete.

Got it, thanks.

Gary> @@ -1736,7 +1739,7 @@ open_verify (const char *name, struct filebuf
Gary> *fbp, struct link_map *loader,
Gary>  	      name = strdupa (realname);
Gary>  	      free (realname);
Gary>  	    }
Gary> -	  lose (errval, fd, name, NULL, NULL, errstring, NULL);
Gary> +	  lose (errval, fd, name, NULL, NULL, errstring, NULL, 0);
Gary>  	}

Paul> Shouldn't the last parameter to lose() above be nsid?

It's ignored because the second-to-last parameter is NULL.
I could add a comment here to clarify if that would help?

Paul> Also, a general comment. One of the reasons the current r_debug
Paul> interface is painful is that the debugger is told: "the link_map
Paul> may have changed, go figure it out". When there are 5000 shared
Paul> libraries loaded (as is routinely the case here at Google), it
Paul> takes a loooong time for GDB to figure out whether anything in
Paul> fact did change, and exactly what. IIRC, at process startup, we
Paul> get one RT_CONSISTENT for each added DSO, and GDB re-scans the
Paul> entire link_map list on each one, resulting in quadratic
Paul> behavior.

Paul> Since we are now defining a brand-new interface, it would be
Paul> nice to make it possible for the debugger to be more efficient.

I spoke with a Google engineer at the GCC gathering in London last
year about exactly this use case.  My idea then was that to accelerate
this an extra argument could be added to the map_complete and
reloc_complete probes containing a list of just the updated libraries.
glibc adds new libraries to the end of the list, so you wouldn't even
have to build a list to send, you could just remember the pointer of
the first newly added/relocated object.  I can certainly extend this
patch now to add this extra argument if you would like.

Paul> Lastly, could this interface be evolved? I don't know if system
Paul> tap probes already have a mechanism for versioned interface. If
Paul> they do, great. If not, the interface should probably include
Paul> version number somewhere.

Roland> There is no particular versioning mechanism and I'm not aware
Roland> of any plan for the issue having been proposed.  So far the
Roland> only use of sdt.h probes in an "ABI-like" fashion is GDB's use
Roland> of the setjmp/longjmp probes.  For that, (IIRC) Tom Tromey and
Roland> I just decided that it was sufficiently unlikely that these
Roland> probes would change in the future that we could bake the
Roland> expectation of their details into GDB and not really have a
Roland> versioning issue later on, so we could just put the general
Roland> question off.  Perhaps the new rtld probes will be
Roland> sufficiently hairy and less likely to be perfectly right the
Roland> first time that we now need to consider the general issue for
Roland> real.  IMHO that should be done with the participation of the
Roland> systemtap and gdb mailing lists, rather than just coming up
Roland> with something ad hoc here.

As it stands, the interface can certainly be extended, in that you can
add new probes without affecting the original ones, and you can add
new arguments to probes without breaking backwards compatibility so
long as the new arguments come after the old ones.  My idea was that
rather than defining a specific interface number, debuggers etc could
simply look for the probes they want and check that they had at least
the number of arguments they expected.  With the current GDB patch,
for example, GDB looks up (OTOH) six probes, and if it finds them all
then it uses them.  If not it falls back to using _dl_debug_state.

If it did turn out that an existing probe was totally broken in some
unrepairable way then a new probe with a different name could be
created that did the right thing.  The problem probe could be either
be removed or retained with its failings documented.  My feeling was
that doing it like this allowed for a smoother upgrade path than some
version number that would cause debuggers to reject the entire
interface when bumped.

It seemed to me that the flexibility you get with being able to look
up the probes you require by name at runtime (combined with not being
locked into a specific argument count) would be enough to future-proof
the design.  I admit I'm no ABI expert, however.  I'm prepared to be
wrong on this, and I'd really like to hear what other people think.

Thanks,
Gary

-- 
http://gbenson.net/


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