Rainer Gerhards <rgerhards@xxxxxxxxx> writes: > What happens is that these reports come up from inside a dlload()'ed > module which is called from the main binary. The main program passes > in two paramaters, a string (pointer to unsigned char) and a pointer > to a function pointer. The module's entry point compares the string > and writes the correct function address to the function pointer. All > accesses to these two variables seem to trigger mudflap violations. > > I have checked the pointer sizes are correctly. > > I have compiled and linked the main program with -fmudflapth > -lmudflapth and have compiled the module with -fmudflapth, but not > linked it with any special directive (my understanding is that > load-time linking will then link the module to the main program's > mudflap libraries, what I think it is the correct thing to do). > > To double-check, I have then linked both the main program and the > module against libmudflapth, and these problems disappear then. So the > conclusion is probably straightforward. However, I still have a hang > condition on some module loads when mudflap is enabled (and only > then). > > So I wonder if I am doing something wrong and if there are any known > problems with dlload(). Any feedback would be appreciated. The mudflap library requires registering all global variables. This is normally done automatically via a global constructor. So one thing to check would be to make sure that that global constructor is being run when you dlopen the shared library. That should normally happen automatically when you call dlopen, at least on GNU/Linux, but perhaps something has gone wrong. You mention dlload several times but I'm not familiar with that function. Ian
