[PATCH v2 1/1] gdb, testsuite, fortran: adapt info symbol expected output for intel compilers

[Kempke, Nils-Christian]

> -----Original Message-----
> From: Joel Brobecker <brobecker@adacore.com>
> Sent: Sunday, January 23, 2022 11:06 AM
> To: Andrew Burgess <aburgess@redhat.com>
> Cc: Kempke, Nils-Christian <nils-christian.kempke@intel.com>; gdb-
> patches@sourceware.org; brobecker@adacore.com
> Subject: Re: [PATCH v2 1/1] gdb, testsuite, fortran: adapt info symbol
> expected output for intel compilers
> 
> > > Info symbol is expected to print the symbol table name of a symbol, since
> > > symbol lookup happens via the minimal symbol table.  This name
> > > corresponds to the linkage name in the full symbol table.
> > >
> > > For gfortran (and maybe others) these names currently have the form
> > > XXXX.NUMBER where XXXX is the symbol name and NUMBER a compiler
> > > generated appendix for mangling.
> > > An example taken from the modified nested-funcs-2.exp would be
> > >
> > > ~~~~
> > > $ objdump -t ./outputs/gdb.fortran/nested-funcs-2/nested-funcs-2 |
> grep \
> > > increment
> > > 00000000000014ab l  F .text  0000000000000095  increment.3883
> > > 000000000000141c l  F .text  000000000000008f
> increment_program_global.3881
> > > ~~~~
> > >
> > > This mangled name gets recognized by the Ada demangler/decoder and
> decoded as
> > > Ada to XXXX (setting the symbol language to Ada).  This leads to output
> > > of XXXX over XXXX.NUMBER for info symbol on gfortran symbols.
> > >
> > > For ifort and ifx the generated linkage names have the form
> > > SCOPEA_SCOPEB_XXXX_ which are not recognized by the Ada decoder
> (or any
> > > other demangler for that matter) and thus printed as is.
> > > The respective objdump in the above case looks like
> > >
> > > ~~~~
> > > $ objdump -t ./outputs/gdb.fortran/nested-funcs-2/nested-funcs-2 |
> grep \
> > > increment
> > > 0000000000403a44 l  F .text  0000000000000074
> contains_keyword_IP_increment_
> > > 0000000000403ab8 l  F .text  0000000000000070
> > > contains_keyword_IP_increment_program_global_
> > > ~~~~
> > >
> > > In the unmodified testcase this results in 'fails' when ran with the intel
> > > compilers:
> > >
> > > ~~~~
> > > >> make check RUNTESTFLAGS="gdb.fortran/nested-funcs-2.exp \
> > > GDBFLAGS='$GDBFLAGS' CC_FOR_TARGET='icpc'
> F90_FOR_TARGET='ifort'"
> > >
> > > ...
> > >
> > >                 === gdb Summary ===
> > >
> > > \# of expected passes            80
> > > \# of unexpected failures        14
> > > ~~~~
> > >
> > > Note that there is no Fortran mangling standard.  We keep the gfortran
> > > behavior as is and modify the test to reflect ifx and ifort mangled
> > > names which fixes above fails.
> > >
> > > Signed-off-by: Nils-Christian Kempke <nils-christian.kempke@intel.com>
> >
> > You might want to wait a couple more days in case Joel wants to follow
> > up, but I think this looks good.
> >
> > If Joel doesn't get back to you, then feel free to push this next
> > week.
> 
> Looks good to me too.
> 
> Just for the sake of completeness, one alternative could have been
> to use gdb_test_multiple, I believe. But both are equally fine
> for me.
> 
> 
> Thanks both!
> --
> Joel

Thanks for the reviews!

As I have neither a Sourceware account nor write access I'd kindly
ask one of you to push the patch on my behalf.

Thanks !

Nils
Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928