This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Question about mudflap
- From: Richard Guenther <richard dot guenther at gmail dot com>
- To: "Frank Ch. Eigler" <fche at redhat dot com>
- Cc: Doug Graham <dgraham at nortel dot com>, gcc at gcc dot gnu dot org
- Date: Wed, 16 Nov 2005 15:23:39 +0100
- Subject: Re: Question about mudflap
- References: <20040629203155.GN10148@redhat.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> <20051116134843.GC1955@redhat.com>
On 11/16/05, Frank Ch. Eigler <fche@redhat.com> 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'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.
A gcc command-line argument could switch behavior, defaulting to off.
But I guess it won't work very well in real-life...
Richard,.