For the following c program:

main(int argc)
{
   typedef
      struct {
      int before_name;
      char name[argc];
      int after_name;
   }
   namet;
  namet n;

}

compiled with gcc 4.7.4, the trunk --read-var-info=yes gives:
parse_type_DIE: confused by:
 <2><51>: DW_TAG_structure_type
     DW_AT_decl_file   : 1	
     DW_AT_decl_line   : 4	
     DW_AT_sibling     : <83>	

This is because that dwarf entry defines a struct with no size.
This happens when the struct has a VLA array in the middle
of a struct. This is a C gcc extension, and is a standard
feature of Ada.
The proper solution would be to have the size calculated at runtime,
using the gnat extensions or dwarf entries (to be generated by
the compiler).


The patch fixes this problem by defining the size of such structure
as 1 byte.
Another approach tried was to put the max possible size.
This had the disadvantage that any address on the stack was seen
as belonging to this variable.
This allows the description to work for the 1st byte of the variable
but cannot properly describe the 2nd and following bytes :
    (gdb) p &n
    $9 = (namet *) 0xbefbc070
    (gdb) mo c d 0xbefbc070
    Address 0xBEFBC070 len 1 not defined:
    Uninitialised value at 0xBEFBC070
    ==1396==  Location 0xbefbc070 is 0 bytes inside n.before_name,
    ==1396==  declared at crec.c:10, in frame #0 of thread 1
    (gdb) mo c d 0xbefbc071
    Address 0xBEFBC071 len 1 not defined:
    Uninitialised value at 0xBEFBC071
    ==1396==  Address 0xbefbc071 is on thread 1's stack
    (gdb) 

A possible refinement would be to use a huge size but have the
logic of variable description understanding this and describing
all between this var and hte next var on the stack as being
in the VLA variable.

In the meantime, the size 1 avoids --read-var-info=yes to fail.


Also, the 'goto bad_DIE' have been replaced by a macro
goto_bad_DIE that ensures the line nr at which the bad DIE has
been detected is reported in the error msg.
This makes it easier to understand what is the problem.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13938 a5019735-40e9-0310-863c-91ae7b9d1cf9
Fix two warnings of unusued variable or variable set but not used


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13939 a5019735-40e9-0310-863c-91ae7b9d1cf9
Enable test cases for SMULH.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13940 a5019735-40e9-0310-863c-91ae7b9d1cf9
On a big application linking with gtk, using the compilation options
-ffunction-sections -fdata-sections and the linker option
-Wl,--gc-sections, --read-var-info=yes gives the following:

    valgrind: m_debuginfo/d3basics.c:973 (vgModuleLocal_evaluate_GX): Assertion 'aMax == ~(Addr)0' failed.

    host stacktrace:
    ==18521==    at 0x38057C54: show_sched_status_wrk (m_libcassert.c:308)
    ==18521==    by 0x38057F50: report_and_quit (m_libcassert.c:367)
    ==18521==    by 0x38058151: vgPlain_assert_fail (m_libcassert.c:432)
    ==18521==    by 0x3813F084: vgModuleLocal_evaluate_GX (d3basics.c:973)
    ==18521==    by 0x38098300: data_address_is_in_var (debuginfo.c:2769)
    ==18521==    by 0x38099E26: vgPlain_get_data_description (debuginfo.c:3298)
    ...

The problem is that -Wl,--gc-sections eliminates the unused functions
but keeps some debug info for the functions or their compilation units.
The dwarf entry has low and high pc, but both are equal to 0.
The dwarf reader of Valgrind is confused by this, as the varstack becomes
empty, while it should not. This then causes local (eliminated) variables
to be put in the global scope, leading afterwards to evaluation errors
when describing any other variables.

The fix is to also push something on the varstack when
a CU that has low and high pc given but with 0 value.
This is similar to the varstack_push done for a CU that has
no low pc, no high pc and no range.
Despite considerable effort to make a small reproducer, the problem
could only be produced with a big executable.
After the fix, everything was working properly.

The wrong behaviour for dwarf entries produce the following trace:
     <2><2ff291a>: Abbrev Number: 23 (DW_TAG_formal_parameter)
         DW_AT_name        : AET	
         DW_AT_decl_file   : 1	
         DW_AT_decl_line   : 243	
         DW_AT_type        : <2ff2811>	
         DW_AT_location    : 18288554	
      Recording this variable, with 1 PC range(s)
    ....
    <2ff291a> addVar: level 0: AET :: EdgeTableEntry*
      Loc=GX(final){[0x0,0x8]=50,[0x9,0x1d]=53,[0x1e,0x26]=51,[0x27,0x29]=53,[0x2a,0x2f]=51,[0x44,0x4a]=53,[0x4d,0x5e]=51,[0x5f,0x62]=53}
      FrB=none
      declared at: gdkpolyreg-generic.c:243
      ACQUIRE for range(s) [0x0,0xffffffff] 

The AET is a formal parameter of a function, but is wrongly added
at level 0, with a PC range covering the full space. It has a Loc GX
which uses non biased program counters (e.g. 0x0,0x8).
This dwarf entry will require a FrB (and registers when evaluating)
but no such things are available (or given) when evaluating a variable
in the global scope.

The fix is to handle compilation units with lo and hi pc == 0x0
similarly to a CU that has no lo and hi pc.
With this fix, valgrind --read-var-info=yes could properly
handle a big application with plenty of eliminated functions.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13941 a5019735-40e9-0310-863c-91ae7b9d1cf9
* document the %ps / %pS extensions to printf
* remove (from memcheck) emiN, as PRINTF_CHECK can be done properly


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13942 a5019735-40e9-0310-863c-91ae7b9d1cf9