[VTA, PR41473] drop NULL locations from lists

Tristan Gingold gingold@adacore.com
Wed Nov 25 08:58:00 GMT 2009


On Nov 24, 2009, at 9:03 PM, Jack Howarth wrote:

> 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,
>  How could readelf show anything as these are MACH-O binaries?

You can try objdump -Wi instead!



More information about the Gcc-patches mailing list