[VTA, PR41473] drop NULL locations from lists

[Jack Howarth]

On Wed, Nov 25, 2009 at 09:33:11AM +0100, Tristan Gingold wrote:
> 
> 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!


Using binutils 2.17-3 from fink, I am not having any luck dumping the dwarf
on darwin. For i386 or x86_64 object files...

objdump --target=mach-o-le --architecture=i386 -Wi foobar.o

or

objdump --target=mach-o-le --architecture=x86_64 -Wi foobar.o

only produces...

BFD header file version 2.17
mach-o-be
 (header big endian, data big endian)
  i386
  powerpc:common
  rs6000:6000
mach-o-le
 (header little endian, data little endian)
  i386
  powerpc:common
  rs6000:6000
mach-o-fat
 (header big endian, data big endian)
  i386
  powerpc:common
  rs6000:6000
pef
 (header big endian, data big endian)
  i386
  powerpc:common
  rs6000:6000
pef-xlib
 (header big endian, data big endian)
sym
 (header big endian, data big endian)
  i386
  powerpc:common
  rs6000:6000
srec
 (header endianness unknown, data endianness unknown)
  i386
  powerpc:common
  rs6000:6000
symbolsrec
 (header endianness unknown, data endianness unknown)
  i386
  powerpc:common
  rs6000:6000
tekhex
 (header endianness unknown, data endianness unknown)
  i386
  powerpc:common
  rs6000:6000
binary
 (header endianness unknown, data endianness unknown)
  i386
  powerpc:common
  rs6000:6000
ihex
 (header endianness unknown, data endianness unknown)
  i386
  powerpc:common
  rs6000:6000

               mach-o-be mach-o-le mach-o-fat pef pef-xlib sym srec symbolsrec 
          i386 mach-o-be mach-o-le mach-o-fat pef -------- sym srec symbolsrec 
powerpc:common mach-o-be mach-o-le mach-o-fat pef -------- sym srec symbolsrec 
   rs6000:6000 mach-o-be mach-o-le mach-o-fat pef -------- sym srec symbolsrec 

               tekhex binary ihex 
          i386 tekhex binary ihex 
powerpc:common tekhex binary ihex 
   rs6000:6000 tekhex binary ihex 

Why do we need this anyway? Isn't their sufficient information in the
generated assembly in PR41473 now with -dA? I certainly see the occurances
of the offending...

.byte	0x0	# DW_AT_location

in those assembly files.
                Jack