mudflap and dlopen

mudflap and dlopen

[Rainer Gerhards]

Hi all,

I hope this is the right mailing list. I am the author of rsyslog, a
modular and multi-threaded syslogd. I try to hunt down a memory
adressing problem with mudflap, but I get some reports that I really
can't understand.

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.

Thanks,
Rainer

Re: mudflap and dlopen

[Ian Lance Taylor]

Rainer Gerhards <rgerhards@gmail.com> 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