[RFC][PATCH 1/1] gdb, testsuite, fortran: adapt info symbol expected output for intel compilers
Kempke, Nils-Christian
nils-christian.kempke@intel.com
Tue Jan 4 11:33:49 GMT 2022
Hi Joel,
> -----Original Message-----
> From: Gdb-patches <gdb-patches-bounces+nils-
> christian.kempke=intel.com@sourceware.org> On Behalf Of Joel Brobecker
> via Gdb-patches
> Sent: Wednesday, December 29, 2021 5:53 AM
> To: Nils-Christian Kempke via Gdb-patches <gdb-patches@sourceware.org>
> Cc: Joel Brobecker <brobecker@adacore.com>
> Subject: Re: [RFC][PATCH 1/1] gdb, testsuite, fortran: adapt info symbol
> expected output for intel compilers
>
> Hi Nils-Christian,
>
> On Tue, Dec 21, 2021 at 02:31:36PM +0100, Nils-Christian Kempke via Gdb-
> patches wrote:
> > 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 and demangled
> 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 demangler
> (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'"
>
> Small note which is absolutely unimportant, but in the spirit of
> sharing: In Ada, the term we use is encode and decode, as opposed
> to mangle and demangle. The late Robert Dewar used to insist on that,
> and now I forgot why it was important to him.
>
> Anyways, in your case, what you are telling us is that the Ada decoder
> is seeing the trailing .DIGITS suffix and therefore stripping it.
> For minimal symbols, I don't see any way around preventing the Ada
> decoder from kicking in, without adversely affecting Ada support
> in return.
>
> For Fortran, you mention that this improves the output. The two
> criteria I often apply in judging how GDB displays the name of
> some symbols are:
>
> - Does the name being displayed match the name in the source code?
> In this case, users would easily recognize "increment", while
> it will be a bit less natural for them to recognize
> "contains_keyword_IP_increment_".
In both cases one can meaningfully use the print and info symbol
commands with the source name for the variable "increment".
So
~~~~
(gdb) print increment
~~~~
works just fine. The difference really lies in the "info symbol" command
where the gfortran compiled executable output looks like
~~~~
(gdb) info symbol increment
increment in section .text of <path_to_executable>/nested-funcs-2
~~~~
while in the ifort/ifx case one gets the a bit more expected
~~~~
(gdb) info symbol increment
contains_keyword_IP_increment_ in section .text of <path_to_executable>/nested-funcs-2
~~~~
Since there is not actually a symbol "increment" in the .text section of
the gfortran generated executable, the first output is slightly wrong and
one has to mentally map the increment to its actual symbol increment.3883.
This should be obvious in most cases though.
>
> - Is GDB able to accept the symbol name as shown in an expression.
> For instance, if GDB displays the symbol as "increment.3883",
> can we use that as the symbol name in an expression, e.g.:
>
> (gdb) print increment.3883
>
> (probably not?)
>
This does indeed not work (I also thought one has to escape the special
character "." but that did not work for me as shown below). I did the
following for the two executables (ifx and gfrotran, there is no
difference between ifx or ifort):
ifx:
~~~~
gdb ./nested-funcs-2
(gdb) r
(gdb) info symbol contains_keyword_IP_increment_
contains_keyword_IP_increment_ in section .text of <path_to_executable>/nested-funcs-2
~~~~
gfortran:
~~~~
gdb ./nested-funcs-2
(gdb) r
(gdb) info symbol increment
No symbol "increment" in current context.
(gdb) info symbol 'increment.3883'
Value can't be converted to integer.
(gdb) info symbol 'increment.3883'
Value can't be converted to integer.
~~~~
The gfortran behavior seems odd and I am not able to actually print the
symbol. In the original email I followed the nested-funcs-2.exp test
and always set a breakpoint at line 60 - here "info symbol increment"
works since we are in the scope of the contains section where the
increment function lives (also a breakpoint at e.g. line 41 would do).
Even so, I can find its entry in the msymbols via
~~~~
(gdb) maint print msymbols
...
[25] t 0x14ab increment.3883 section .text increment nested-funcs-2.f90
...
~~~~
Also, in the gfortran case the tab complete completes my input to
"increment' while in the ifx case (where there is no such symbol) a
"info symbol incre" does not get tab-completed.
> These consideration tend to drive how the decoder and the language
> expression parser are written.
>
> Coming back to this patch, I think the solution you chose is fine.
> Note that, for master (and for GDB 12 branches and later), we no
> longer require a ChangeLog entry.
Ah, yes, thanks!
So I think the above oddity of not being able to print the actual symbol
in the gfortran case results from the decoding but I do not know what
to do against it.
It also does not seem to impair usability too much - only if someone tries
to specifically print a symbol they found in the symbol table maybe. Else,
the gdb printed symbol "increment" can be queried (as long as one is
withing the scope where it is visible).
>From my point I'd go on and submit the patch without Changelog and
a little more care to endoce/decode ;)
Thanks!
-Nils
>
> >
> > ...
> >
> > === 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.
> >
> > gdb/testsuite/ChangeLog:
> > 2021-12-20 Nils-Christian Kempke <nils-christian.kempke@intel.com>
> >
> > * gdb.fortran/nested-funcs-2.exp: Adapt expected output for info
> > symbols on ifx and ifort.
> >
> > Signed-off-by: Nils-Christian Kempke <nils-christian.kempke@intel.com>
> > ---
> > gdb/testsuite/gdb.fortran/nested-funcs-2.exp | 29
> ++++++++++++++++++--
> > 1 file changed, 27 insertions(+), 2 deletions(-)
> >
> > diff --git a/gdb/testsuite/gdb.fortran/nested-funcs-2.exp
> b/gdb/testsuite/gdb.fortran/nested-funcs-2.exp
> > index f679529478..5bd4e3706a 100644
> > --- a/gdb/testsuite/gdb.fortran/nested-funcs-2.exp
> > +++ b/gdb/testsuite/gdb.fortran/nested-funcs-2.exp
> > @@ -50,6 +50,31 @@ proc do_bp_tests {with_src_prefix_p
> with_nest_prefix_p} {
> > set nest_prefix ""
> > }
> >
> > + # FIXME: Normally, info symbol should print the symbol table name for
> any
> > + # fortran symbols (since symbol lookup happens via the minimal symbol
> > + # table). This would correspond 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. This mangled name gets recognized by the
> Ada
> > + # demangler and demangled as Ada (setting the symbol language to
> Ada) to
> > + # XXXX. This leads to the somewhat unexpected output of XXXX over
> > + # XXXX.NUMBER for info symbol.
> > + # For ifort and ifx the generated linkage names have the form
> > + # SCOPEA_SCOPEB_XXXX_ which are not recognized by the Ada
> demangler and
> > + # thus printed as is.
> > + # Note that there is no Fortran mangling standard. We keep the
> > + # gfortran behavior as is and extend the test to reflect ifx and ifort
> > + # mangling.
> > + proc get_linkage_name_pattern {symbol_name} {
> > +
> > + if { [test_compiler_info icc*] } {
> > + return "\(?:.*_\)?${symbol_name}_?"
> > + } else {
> > + return ${symbol_name}
> > + }
> > + }
> > +
> > # Test setting up breakpoints and otherwise examining nested
> > # functions before the program starts.
> > with_test_prefix "before start" {
> > @@ -68,7 +93,7 @@ proc do_bp_tests {with_src_prefix_p
> with_nest_prefix_p} {
> > # is a failure, just a limitation in current GDB.
> > if { ${with_nest_prefix_p} } {
> > gdb_test "info symbol ${nest_prefix}${function}" \
> > - "${function} in section .*"
> > + "[get_linkage_name_pattern ${function}] in
> section .*"
> > gdb_test "whatis ${nest_prefix}${function}" \
> > "type = ${type}"
> > gdb_test "ptype ${nest_prefix}${function}" \
> > @@ -134,7 +159,7 @@ proc do_bp_tests {with_src_prefix_p
> with_nest_prefix_p} {
> > set type [lindex $entry 1]
> > with_test_prefix $function {
> > gdb_test "info symbol ${nest_prefix}$function" \
> > - "$function in section .*"
> > + "[get_linkage_name_pattern $function] in section
> .*"
> > gdb_test "whatis ${nest_prefix}$function" \
> > "type = ${type}"
> > gdb_test "ptype ${nest_prefix}$function" \
> > --
> > 2.25.1
> >
> > 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
> >
>
> --
> Joel
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
More information about the Gdb-patches
mailing list