This is the mail archive of the mailing list for the GCC 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: wrap functions in glibc

Hi Andrew,

> However, if I want to wrap function calls in library (e.g. memcpy), what should I do?

In your main application executable, create your own function (e.g. memcpy) with the same signature as the one you want to replace, which will include the public memcpy used by shared libraries.

Make sure your memcpy is externally linkable and externally visible.  (The "visibility" facility varies by platform.  A glaring omission in the C++ specification, in my opinion.  The oversight which has been implemented very differently by different compiler vendors.)

In your memcpy, you can re-implement the functionality as you see fit.

OR... if you just want to "wrap" the original but instrument the original memcpy with some extra stuff (say, debug tracking or diagnostic information), and the original memcpy is in a DLL, you can refer to the original memcpy by accessing that DLL as a DSO (instead of a SSO).  Using such facilities as dlopen or LoadLibrary.  (The exact facility can vary by platform.  Again, it would be nice if there was a uniform mechanism.  Alas.)  Then when you have the function pointer, you can instrument your own memcpy as you see fit with prologue or epilogue code around the original memcpy, which your routine would call as a function pointer.

The one big caveat is that DLLs which are strongly bound and have their own internal memcpy, or if memcpy was inlined, will not use your instrumented version.


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