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] |
On 10/22/13 15:06, Joseph S. Myers wrote:
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.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 libraries.
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.
Jeff
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |