Re: Question about mudflap

2005-11-16 Thread Doug Graham
On Wed, Nov 16, 2005 at 08:48:43AM -0500, Frank Ch. Eigler wrote:
> Hi -
> 
> > What I'm wondering is whether or not mudflap should instrument accesses
> > to globals that it doesn't know the size of.  In the following code:
> > [...]
> >  printf("%d\n", global[3]);
> > [...] Mudflap does not emit any __mf_check calls.
> 
> It is probably kicking in an optimization that says that if the
> indexes are literals and thus statically checkable against array
> bounds, then there is no need for a runtime check.  The problem here
> is of course that we can't do the static check after all because of
> the extern[].  There is also another complication (unhelpful
> TREE_ADDRESSABLE flag setting for this and a few other cases).

I wondered about that.  So I varied the test program to use argc
as the array index instead of a constant.  Still no __mf_check.

   int main(int argc, char **argv) {
  printf("%d\n", global[argc]);

> > [...]  I'd much prefer if it did go on and check all accesses to the
> > array because in my case, global[] will always be registered by the
> > compilation unit in which it is defined.  [...]
> 
> On the other hand, mudflap can't know that this extern[] will be
> registered by that other compilation unit, since that might be
> compiled without -fmudflap.  An mf_check against it would then fail.

That's true.  The default should probably be to not warn about accesses
to objects that mudflap doesn't know about, and then have a runtime
option, say, -warn-unchecked-statics, to tell it to issue the warning.
That idea is stolen from the Jones bounds-checking patches, but I suspect
that it works better there than it would with mudflap.  If mudflap didn't
warn about accesses to unknown objects, that raises the question of just
what it could warn about.

Anyway, it doesn't sound as though this lack of an __mf_check is a
deliberate design choice, which is good.

--Doug.


Re: a mudflap experiment on freebsd

2005-02-23 Thread Doug Graham
On Wed, Feb 23, 2005 at 12:49:41PM -0500, Frank Ch. Eigler wrote:
> Regarding memory consumption, perhaps libmudflap's default backtrace
> parameter should be set to zero, for both speed and space reasons.

If it's storing all the backtraces that is burning up all the memory,
another approach might be to keep a separate hash table for storing
backtraces, then hash new backtraces and see if the same backtrace already
exists from a previous call to malloc.  If so, no need to allocate a
new one.  That's essentially what the hprof Java profiler does, and it
works pretty well.  The average application might have many thousands
of mallocs, but only a few distinct backtraces.  Also, saving program
counters instead of symbolic names in the backtrace would probably save
a lot of memory, and might also make hashing the backtrace cheaper.
Or the strings containing the symbolic names could be internalized rather
than allocating a new string for every symbolic name in every backtrace.

Internalizing entire backtraces also makes it simple to collect statistics
on where the memory is being allocated from.

--Doug.