Alan Coopersmith wrote: > Ali Bahrami wrote: >> I can't think of any facility in the Solaris ld that >> can do that as described. >> >> The closest thing would be to preload a sharable object >> that provided the wrapper functions, which then use dlsym >> at runtime to find and call the real function. >> >> I assume that the obvious idea of doing this at compile time >> with macros has been rejected? >> >> #define malloc __wrap_malloc > > The problem with doing this at compile time is then you have to > compile two versions of the objects - one for production, one for > testing. > > Xorg is using this to call the same .o's and *.so's used in production > from the test harness, just wrapping input/output functions to control > the input and then validate the output is as expected - this is > described a bit more, with links to some examples, at: > http://lists.x.org/archives/xorg-devel/2009-June/001099.html > > You could imagine doing something similar to test functions in any > shared library - for instance, a test for the new asprintf function > added recently to libc might wrap malloc to make sure it's mallocing > the expected size before calling the wrapped malloc to do the actual > allocation, or may return 0 to make sure it handles allocation failure > correctly. > > I'll file an RFE for consideration for this in the Solaris ld, > since I think most of the runtime side is there in the existing > interposer functionality, would just need the linker to do the > grunt work of defining the interposers for you. >
So I can see that you'd have to rebuild the test harness for the macro idea to work, but did not think you'd have to rebuild the objects being wrapped. I gather from your description above, that what is really happening here is that the test harness is linked with the production .o's into an executable, and that we want the calls within the production .o's to also be wrapped, not just the ones that originate in the test harness code. If that's right, then I can see why the macro idea won't fly, and that the linker would have to be involved to make it happen. You say "to call the same .o's and *.so's used in production". I can so how this works with .o's, since the link-editor is combining them into the output. I don't follow how it inserts wrapping into an already built .so though. Can you explain that part for me? (Is your reference to interposers part of that answer?) Thanks... - Ali
