tree-ssa -fmudflap problems

[Eyal Lebedinsky]

"Frank Ch. Eigler" wrote:
> > OK, it may be evident that I know pittifully little about the
> > situation with tree-ssa in general and mudflap in particular.
> > Where can I find some information to bring me up to speed?
> 
> Other than the source code, the gcc-patches discussions, and a
> paper for the GCC Summit I'm drafting about it, there isn't a lot
> to read.  If perhaps you have specific questions, I can have them
> answered in the paper.

I do want to find out more about mudflap. Here is how I see the whole
idea of pointer tracking.

One way is to establish a registry of all valid memory areas, and
then pointers are validated by checking them against this registry.
I have such a debug system implemeneted in our software, however
it only tracks dynamic memory (malloc/free etc.) automatically.
In order to validate all memory I need to manually make calls
to register static memory and auto memory. A compiler can do this
last bit nicely. My system in thread safe. The registry is a B-tree
thus allowing us to find the object that a pointer falls into.
My system is also limited to checking pointers at key points (e.g.
at mem*() and str*() funcs etc.) while a compiler can validate a
pointer at every use. In short, a compiler can make better use of
the pointer registry that we already have.

Another way is to make the C pointer type carry more than just the
memory address, but also the start/end of the memory area that it
can validly address. We can now easily verify that the pointer
is not used outside its designated range. The hard part here is
that when interacting with external functions one needs to convert
the fat pointers to the standard ones and back (not always possible).
There needs to be a way to tell when a called function expects fat
or std arguments.

Is mudflap using something like the above two? Something else?

I decided to try and get my system to first base. I created a small
header and function that loads all the required pthread_ functions
(dlopen/sym) into a structure, and then (using some #defines)
replaces all pthread_XXX() calls with a call through the structure,
like this
	(*my_struct.my_pthread_XXX)()

All I changed was replacing
	#include <pthread.h>
with
	#include "pt.h"
where needed, and added a call at system initialisation to the
library load function that populates the structure.

This should remove all dependency on -lpthread. It did not. Not
only did I find my executables having a dependency (ldd) on
libpthread.so, but the programs fails (a stack overflow) on the first
dlopen("/usr/lib/libpthread.so").

Is there an internal dependency that gcc inserts somehow? I did not
include <pthread.h> and did not mention any of pthread_ function.

My intention is to run some of my simple programs, which do not
actually start another thread yet. I understand that this should
be achievable at this point.

--
Eyal Lebedinsky (eyal@eyal.emu.id.au) <http://samba.org/eyal/>