[Pointer,Bounds,Checker,29/x] Debug info

Hi,

This patch skips all bounds during debug info generation.

Bootstrapped and tested on linux-x86_64.

Thanks,
Ilya
--
gcc/

2014-06-11  Ilya Enkovich  <ilya.enkovich@intel.com>

	* dbxout.c (dbxout_type): Ignore POINTER_BOUNDS_TYPE.
	* dwarf2out.c (gen_subprogram_die): Ignore bound args.
	(gen_type_die_with_usage): Skip pointer bounds.
	(dwarf2out_global_decl): Likewise.
	(is_base_type): Support POINTER_BOUNDS_TYPE.
	(gen_formal_types_die): Skip pointer bounds.
	(gen_decl_die): Likewise.
	* var-tracking.c (vt_add_function_parameters): Skip
	bounds parameters.

On 06/11/14 02:50, Ilya Enkovich wrote:
> Hi,
>
> This patch skips all bounds during debug info generation.
>
> Bootstrapped and tested on linux-x86_64.
>
> Thanks,
> Ilya
> --
> gcc/
>
> 2014-06-11  Ilya Enkovich  <ilya.enkovich@intel.com>
>
> 	* dbxout.c (dbxout_type): Ignore POINTER_BOUNDS_TYPE.
> 	* dwarf2out.c (gen_subprogram_die): Ignore bound args.
> 	(gen_type_die_with_usage): Skip pointer bounds.
> 	(dwarf2out_global_decl): Likewise.
> 	(is_base_type): Support POINTER_BOUNDS_TYPE.
> 	(gen_formal_types_die): Skip pointer bounds.
> 	(gen_decl_die): Likewise.
> 	* var-tracking.c (vt_add_function_parameters): Skip
> 	bounds parameters.
OK.  Note that sdbout might need updating as well.   It's used even less 
than dbxout, but if you can see how to skip bounds in there to, it'd be 
appreciated.

It looks like mingw/cygwin still use sdbout (?!?), so if you need 
something tested, you can ping Kai Tietz.

jeff

2014-06-18 0:56 GMT+04:00 Jeff Law <law@redhat.com>:
> On 06/11/14 02:50, Ilya Enkovich wrote:
>>
>> Hi,
>>
>> This patch skips all bounds during debug info generation.
>>
>> Bootstrapped and tested on linux-x86_64.
>>
>> Thanks,
>> Ilya
>> --
>> gcc/
>>
>> 2014-06-11  Ilya Enkovich  <ilya.enkovich@intel.com>
>>
>>         * dbxout.c (dbxout_type): Ignore POINTER_BOUNDS_TYPE.
>>         * dwarf2out.c (gen_subprogram_die): Ignore bound args.
>>         (gen_type_die_with_usage): Skip pointer bounds.
>>         (dwarf2out_global_decl): Likewise.
>>         (is_base_type): Support POINTER_BOUNDS_TYPE.
>>         (gen_formal_types_die): Skip pointer bounds.
>>         (gen_decl_die): Likewise.
>>         * var-tracking.c (vt_add_function_parameters): Skip
>>         bounds parameters.
>
> OK.  Note that sdbout might need updating as well.   It's used even less
> than dbxout, but if you can see how to skip bounds in there to, it'd be
> appreciated.
>
> It looks like mingw/cygwin still use sdbout (?!?), so if you need something
> tested, you can ping Kai Tietz.
>
> jeff
>

I looked into sdbout.c code and didn't find any places requiring
fixes.  It seems it just ignores cases when it doesn't know what to
output.

To make some runtime tests I put SDB_DEBUGGING_INFO definition into
config/i386/x86-64.h and got linux compiler with sdb support.  Then I
used this compiler with -gcoff option on C benchmarks from SPEC2000.
There are 4 benchmarks on which compiler fails with ICEs.  All of them
with the same error:

cc1: internal compiler error: in needed_p, at cgraphunit.c:237
0x7c1a8c symtab_node::needed_p()
        ../../gcc-pl/gcc/cgraphunit.c:236
0x7c3933 analyze_functions
        ../../gcc-pl/gcc/cgraphunit.c:936

All other benchmarks compile OK and when I add '-fcheck-pointer-bounds
-mmpx' no new failures appear.

I couldn't fully build compiler under cygwin (it breaks somewhere on
library build) but I used obtained cc1.exe compiler on a source file
which caused ICE on linux and got the same failure.  So, I believe I
should expect the same results under cygwin.  Would it be enough to
say checker should be OK with sdbout?

BTW seems ICE appears when the same name is used for structure field
and a static var.  I get fail with the following testcase:

typedef struct {
  int *next;
} list;

int *next;

int main(int argc, char **argv)
{
  return 0;
}

Test stops to fail if I rename either field of static var.  It looks
like sdbout outputs type info and mark name 'next' as referenced.
Later it causes assert failure in symtab_node::needed_p when it checks
symbol's assembler name is not referenced.  Will submit a bug for it
but doubt someone is waiting for it to be fixed :)

Thanks,
Ilya

On 10/15/14 09:54, Ilya Enkovich wrote:
>
> I looked into sdbout.c code and didn't find any places requiring
> fixes.  It seems it just ignores cases when it doesn't know what to
> output.
Perfect.  I really don't want to invest developer time into 
significantly improving sdbout or dbxout.  If sdbout is ignoring 
anything it doesn't understand, then that's good enough for me.

>
> To make some runtime tests I put SDB_DEBUGGING_INFO definition into
> config/i386/x86-64.h and got linux compiler with sdb support.  Then I
> used this compiler with -gcoff option on C benchmarks from SPEC2000.
> There are 4 benchmarks on which compiler fails with ICEs.  All of them
> with the same error:
>
> cc1: internal compiler error: in needed_p, at cgraphunit.c:237
> 0x7c1a8c symtab_node::needed_p()
>          ../../gcc-pl/gcc/cgraphunit.c:236
> 0x7c3933 analyze_functions
>          ../../gcc-pl/gcc/cgraphunit.c:936
>
> All other benchmarks compile OK and when I add '-fcheck-pointer-bounds
> -mmpx' no new failures appear.
>
> I couldn't fully build compiler under cygwin (it breaks somewhere on
> library build) but I used obtained cc1.exe compiler on a source file
> which caused ICE on linux and got the same failure.  So, I believe I
> should expect the same results under cygwin.  Would it be enough to
> say checker should be OK with sdbout?
Yea, I think that's sufficient.  Thanks for going the extra mile on this.


>
> BTW seems ICE appears when the same name is used for structure field
> and a static var.  I get fail with the following testcase:
>
> typedef struct {
>    int *next;
> } list;
>
> int *next;
>
> int main(int argc, char **argv)
> {
>    return 0;
> }
>
> Test stops to fail if I rename either field of static var.  It looks
> like sdbout outputs type info and mark name 'next' as referenced.
> Later it causes assert failure in symtab_node::needed_p when it checks
> symbol's assembler name is not referenced.  Will submit a bug for it
> but doubt someone is waiting for it to be fixed :)
Yes, please submit a bug.  I doubt it'll be considered high priority, 
but it might make a good project for someone to poke at in a free 
afternoon :-)

jeff