[VTA, PR41473] drop NULL locations from lists

[Jack Howarth]

On Tue, Nov 24, 2009 at 12:30:44AM -0200, Alexandre Oliva wrote:
> On Nov 23, 2009, Jack Howarth <howarth@bromo.med.uc.edu> wrote:
> 
> >     It appears that we still must be missing some cases were
> > AT_location is being set to zero
> 
> Can you name any?  I'm using a cross compiler, so I need a testcase that
> triggers the problem, its assembly with -dA comments and an indication
> of where the problem is in it.
> 
> -- 
> Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
> You must be the change you wish to see in the world. -- Gandhi
> Be Free! -- http://FSFLA.org/   FSF Latin America board member
> Free Software Evangelist      Red Hat Brazil Compiler Engineer

Alexandre,
   I have some comments from the dsymutil maintainer regarding the ssp.s
testcase that I added to PR41473...

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

On Nov 24, 2009, at 7:48 AM, Jack Howarth wrote:

> Greg,
>  I have narrowed down the offending source code in libssp.0.dylib
> which still asserts dsymutil in FSF gcc trunk when built with...
>
> http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01329.html
>
> (that is supposed to eliminate the NULL locations in the
> dwarf output). The offending code from ssp.c as assembly
> to attached at...
>
> http://gcc.gnu.org/bugzilla/attachment.cgi?id=19109
>
> When compiled as..
>
> as -arch x86_64 ssp.s -o ssp.o
>
> and linked as
>
> gcc -arch x86_64 -dynamiclib ssp.o -o test.dylib
>
> , the resulting test.dylib asserts dsymutil. I will
> update the ssp.s later tonight to be built with -dA
> so that it is easier to read. In the meanwhile,
> can you tell me if your patched dsymutil can process
> this file?

It does!


> Or is this some new issue with zero
> AT_locations beyond the previous block forms?

There are still zero length blocks in the resulting .o file which is what is crashing dsymutil:

% dwarfdump --verbose --show-form ssp.o
....
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 )

> Thanks
> in advance for any information. It would be helpful
> if we can provide Alexandre Oliva with any additional
> details on why this is asserting dsymutil since he 
> is quite willing to make the effort to work around the
> limitations in the current darwin dsymutils for
> gcc 4.5.

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 )

Usually when you have a location with a FORM_block1, the entire location will be displayed on the same line. There is a good example for "fd"
+in ssp.o:

0x0000027c:         TAG_variable [12]
0x0000027d:          AT_name[FORM_string] ( "fd" )
0x00000280:          AT_decl_file[FORM_data1] ( 0x01 ( "../../../gcc-4.5-20091123/libssp/ssp.c" ) )
0x00000281:          AT_decl_line[FORM_data1] ( 0x68 ( 104 ) )
0x00000282:          AT_type[FORM_ref4] ( cu + 0x00000108 => {0x00000108} ( int ) )
0x00000286:          AT_location[FORM_block1] ( <0x1> 5d  ( reg13 ) )


Note how the block shows the length of the block as in between less than/greater than chars above.

The following command will allow you to use the existing dwarfdump to find any remaining zero length block issues:

% /usr/bin/dwarfdump --verbose --show-form ssp.o | grep -C5 'AT_location.*FORM_block[^<]+$'
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 )





>              Jack
> ps I plan on working my way through all of the
> remaining shared libraries in FSF gcc that still
> assert dsymutil with the proposed patch and identify
> the specific object files containing the offending
> code. I should add that I was very surprised last
> night to see libgcj not assert dsymutil during the
> build with the first version of the proposed patch
> but to assert dsymutil with the second revision.
> The weird bit was that when I manually ran dsymutil
> on the libgcj outside of the build it didn't assert.
> Odd.

It all comes down to luck of the draw with these binaries, as dsymutil might not 
assert depending on what gets erroneously written where...
dsymutil is incorrectly putting data into the middle of the DWARF debug 
info and might cause an assert if we change the abbreviation code for a DIE (debug info entry).

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

Oddly, I see the section from '/usr/bin/dwarfdump --verbose --show-form ssp.o' that is supposed to
have the zero AT_location...

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 )

that he mentions but...

 /usr/bin/dwarfdump --verbose --show-form ssp.o | grep -C5 'AT_location.*FORM_block[^<]+$'

produces no output. I am looking at these binaries under Leopard instead of SL so
it could be some oddity from that combination. In any case, I will add the dwarfdump
to the PR.
               Jack