Re: [VTA, PR41473] drop NULL locations from lists

[Jack Howarth <howarth at bromo dot med dot uc dot edu>]

On Tue, Nov 24, 2009 at 11:48:38AM -0800, Cary Coutant wrote:
> > Unfortunately the current dwarfdump won't show these zero length blocks, but you can detect them by looking for a "AT_location" attribute with
> > +"FORM_blockXXX" attributes that have location lists displayed beneath them:
> >
> > 0x00000269: ? ? ? ? TAG_variable [12]
> > 0x0000026a: ? ? ? ? ?AT_name[FORM_string] ( "__progname" )
> > 0x00000275: ? ? ? ? ?AT_decl_file[FORM_data1] ( 0x01 ( "../../../gcc-4.5-20091123/libssp/ssp.c" ) )
> > 0x00000276: ? ? ? ? ?AT_decl_line[FORM_data1] ( 0x66 ( 102 ) )
> > 0x00000277: ? ? ? ? ?AT_type[FORM_ref4] ( cu + 0x00000355 => {0x00000355} ( const char[] ) )
> > 0x0000027b: ? ? ? ? ?AT_location[FORM_block1] (
> > ? ? ? ? ? ? ? ? ? ? ? ?0x0000000000000000 - 0x0000000000000001: breg7 +8
> > ? ? ? ? ? ? ? ? ? ? ? ?0x0000000000000001 - 0x0000000000000006: breg7 +16
> > ? ? ? ? ? ? ? ? ? ? ? ?0x0000000000000006 - 0x0000000000000111: breg6 +16 )
> 
> I'm puzzled by this. When an AT_location attribute points to a
> location list, it should be using DW_FORM_data4 or DW_FORM_data8.
> DW_FORM_block1 indicates a single location expression contained in the
> block. This looks like a bug in dwarfdump, as I don't see how a
> DW_FORM_block1 could lead to a location list. What does readelf -wi
> show?
> 
> -cary

Cary,
    The response from the dsymutil maintainer was...

---------------------------------------------------------------------------

As I said, "with the current dwarfdump". The new dwarfdump disassebles the DWARF correctly:

0x00000269:         TAG_variable [12]
0x0000026a:          AT_name[FORM_string] ( "__progname" )
0x00000275:          AT_decl_file[FORM_data1] ( 0x01 ( "../../../gcc-4.5-20091123/libssp/ssp.c" ) )
0x00000276:          AT_decl_line[FORM_data1] ( 0x66 ( 102 ) )
0x00000277:          AT_type[FORM_ref4] ( cu + 0x00000355 => {0x00000355} ( const char[] ) )
0x0000027b:          AT_location[FORM_block1] ( <0x0> EMPTY )


I gave you a hack to tell when you are seeing this issue -- the dwarfdump command with the grep -- and the grep was looking for the discrepancy    
+Cary Coutant was pointing out! :-)

---------------------------------------------------------------------------

So with the current dwarfdump (which doesn't understand zero AT_locations)
we can really only be used to identify where the offending zero AT_locations
are. Does the information above from the new dwarfdump help explain why
Alexandre's proposed patch (http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01329.html)
left thati particular zero AT_location in the emitted dwarf code?
               Jack