This is the mail archive of the 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] Preload infrastructure.

On 10/22/13 15:06, Joseph S. Myers wrote:

So: put this code in the debug/ directory like other debugging preloadable
libraries; split it up by the different things it's usable to debug, so
each installed shared object does one clearly defined thing and does it
well; model the build/install system on how other such libraries are
built/installed; model other things on those libraries as well (such as
using an environment variable to specify an output file, not a hardcoded
/tmp path); generally follow established coding practices for such
Most definitely break it up in some way. For a developer trying to track down a problem, they may already have a clue about the scope of the problem and thus may not want to pay the penalty for every interceptor function.

ie, if they suspect they're doing something wrong in the pthread libraries, paying a 10%+ penalty for memcpy overlap checking is silly.

I would also recommend considering not making these interceptors a part of glibc. They are checking for compliance to various standards which is independent of the library implementation underneath.

I must admit this is a bit selfish -- whatever is done here beyond what's checked by memstomp Red Hat will probably want to package independently of glibc (as we already update our intercept checkers independently of glibc) and we will want to present a consistent way to enable these checks to the user, consistent error reporting, etc.


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