Re: RFC: --enable-checking=valgrind.

[Zack Weinberg <zack@codesourcery.com>]

On Mon, Nov 11, 2002 at 04:55:17AM -0500, Hans-Peter Nilsson wrote:
> > I bet many of those indications will go away if you add annotations to
> > cppfiles.c so that it knows what's going on with mmap().
> 
> Oh right, that cute mmap trick...  With this updated patch, the
> "many-many" indications from cppfiles are replaced by "many",
> for example the following first one.

...

> ==5784== Conditional jump or move depends on uninitialised value(s)
> ==5784==    at 0x81EE503: get_attr_prefix_0f (insn-attrtab.c:23298)
> ==5784==    by 0x81C536E: insn_default_length (insn-attrtab.c:594)
> ==5784==    by 0x817160F: shorten_branches (/home/hp/cvs_areas/gcc/cvs_write/egcs/gcc/final.c:1334)
> ==5784==    by 0x836F421: rest_of_compilation (/home/hp/cvs_areas/gcc/cvs_write/egcs/gcc/toplev.c:3546)
> ==5784==

Hmm.  This is probabably just one bug, in genattrtab, but genattrtab
is such a mess I don't know where to begin looking.

What's on line 23298 of insn-attrtab.c?

> I don't know what causes that "Line number overflow detected"
> message, but perhaps old binutils.

The stabs debug format has a limit of 65535 lines in a single
translation unit; the x86 insn-recog.c is 54827 lines before #include
processing, presumably the headers push it over the edge.  DWARF can
handle this, or we can talk about ways to shrink it.
 
> 	* cppfiles.c (read_include_file) [ENABLE_VALGRIND]: When doing the
> 	mmap+1 trick, annotate the byte after the mmap:ed area as readable.

I think you also need to clear the annotation again when the map is
deallocated, or that one byte might continue to be considered
readable.  Probably want to hang onto the region ID, too.

zw