This is the mail archive of the gcc@gcc.gnu.org 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: a mudflap experiment on freebsd


Hi, Jim -


> A customer expressed interest in mudflap, so I tried to see if I
> could use it compile something large.  [...]

Thanks for giving it a try.

For what it's worth, I've run entire gcc bootstraps on Linux with the
instrumentation running (using BOOT_CFLAGS rather than CFLAGS).  Each
time, it seems to take some tweaks in libmudflap or tree-mudflap to
work again (pass cleanly).  This indicates that there is a source of
regressions that is not represented in the test suite.

Regarding -fmudflap => -lmudflap, it used to do that.  The problem was
that the simplest use of specs machinery creates a final sequence of
"-lFOO" options that sometimes cannot work.  libmudflap must be in a
particular spot on the command line so it can intercept calls into
libc and other libraries, and from libgcc.  Adding -lmudflap once to
the beginning or end of all the libraries/objects is not sufficient
IIRC.

Regarding registering fopen return values, indeed libmudflap needs
autoconf assistance.  The issue is that on some libc implementations,
fopen runs malloc to allocate the FILE, which we can sometimes
intercept in libmudflap.  Other implementations call private routines
that we cannot intercept, so must register fopen return values
manually.

Regarding mmap/malloc recursion, this is similar to the fopen
situation.  Some reentrancy is expected; some is tolerated and
prevented.  You should not have to invent any further static counters
for this stuff: the __mf_state variable should be able to do the right
thing.

Regarding error reports containing good application-level PCs, you're
right that using builtin_return_address(0) is not sufficient for
interior routines.  Solutions would include snapshotting that value on
a border function, hiding it in a per-thread global or widening the
internal interfaces to pass it down.

Regarding varargs, there is a libmudflap test case or two for that.
The most problematic aspect seems to be ensuring that the variables
being passed in varargs slots be registered with libmudflap, so
va_arg() dereferencing is permitted.  I recall at one point va_arg()
being deliberately made uninstrumented, because doing the real
registration work was too difficult.  Either should at least shut
libmudflap up.

Regarding registration of static strings, this is one of the areas
that seems to suffer from tree-ssa churn.  tree-mudflap tries to
arrange string constants and other static objects to be registered,
but I recall tree flags switching interfering with this.  In general
the code is supposed to err on the side of registration.

Regarding memory consumption, perhaps libmudflap's default backtrace
parameter should be set to zero, for both speed and space reasons.

Regarding the torrent of warnings/errors you encountered for the one
or two actual bugs it found, yeah, it's not a great return.  Once
libmudflap is properly ported to *bsd, and the instrumentation-side
regressions are fixed again, it will be much saner.


- FChE


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