This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Question about mudflap
- From: "Frank Ch. Eigler" <fche at redhat dot com>
- To: Doug Graham <dgraham at nortel dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Wed, 16 Nov 2005 08:48:43 -0500
- Subject: Re: Question about mudflap
- References: <20040629203155.GN10148@redhat.com> <20050407172217.GH3512@nortelnetworks.com> <20050407173914.GA15740@redhat.com> <20050407202356.GI3512@nortelnetworks.com> <20050408005509.GD5923@redhat.com> <20050408022625.GL3512@nortelnetworks.com> <20050408114112.GH5923@redhat.com> <20050409213942.GP3512@nortelnetworks.com> <20050410101136.GA9265@redhat.com> <20051116082054.GY3483@nortelnetworks.com>
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'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.
- FChE