tree 4857d2987003eb2e8ce0b8eb13e86e5b64946a98
parent f3ea0d58c82358fe8f5eba1e8770c1f7b2e97b8d
author philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> 1399407355 +0000
committer philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> 1399407355 +0000

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