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

[Jan Hubicka <jh at suse dot cz>]

> 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.
It is probably bug in the machine description.
We use type information to figure out how many arguments instruction
have.
In case it has fewer arugments, we access uninitialized memory that
"usually works :)".  If you will just go to gdb and do "p debug_rtx (insn)"
I think I can fix the bugs easilly.
What we should do in this case is to eighter invent new type or set the
problematic attributes explicitly in the patern... 
valgrind looks really usefull :)

Honza
> 
> 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