* [PATCH v2 0/1] gdb, testsuite, fortran: adapt info symbol expected output for intel compilers
@ 2022-01-17 11:30 Nils-Christian Kempke
2022-01-17 11:30 ` [PATCH v2 1/1] " Nils-Christian Kempke
0 siblings, 1 reply; 6+ messages in thread
From: Nils-Christian Kempke @ 2022-01-17 11:30 UTC (permalink / raw)
To: gdb-patches; +Cc: brobecker, Nils-Christian Kempke
This is version two of a patch that I first had sent to as a RFC
https://sourceware.org/pipermail/gdb-patches/2022-January/184776.html
There were only two changes: first, since
2026dcfcc0c0e60efa968b889f010a10a93cfe09
has been pushed recently, I added ifx as an exception to the test
as well. Second, I incorporated the encode/decode terminology when
talking about Ada.
Cheers,
Nils
Nils-Christian Kempke (1):
gdb, testsuite, fortran: adapt info symbol expected output intel
compilers
gdb/testsuite/gdb.fortran/nested-funcs-2.exp | 29 ++++++++++++++++++--
1 file changed, 27 insertions(+), 2 deletions(-)
--
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH v2 1/1] gdb, testsuite, fortran: adapt info symbol expected output for intel compilers
2022-01-17 11:30 [PATCH v2 0/1] gdb, testsuite, fortran: adapt info symbol expected output for intel compilers Nils-Christian Kempke
@ 2022-01-17 11:30 ` Nils-Christian Kempke
2022-01-21 16:49 ` Andrew Burgess
0 siblings, 1 reply; 6+ messages in thread
From: Nils-Christian Kempke @ 2022-01-17 11:30 UTC (permalink / raw)
To: gdb-patches; +Cc: brobecker, Nils-Christian Kempke
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>
---
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 d04fd0987e..6009cb65c5 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 ""
}
+ # Normally, info symbol prints 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/decoder and decoded 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 is 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*] || [test_compiler_info intel*]} {
+ 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2 1/1] gdb, testsuite, fortran: adapt info symbol expected output for intel compilers
2022-01-17 11:30 ` [PATCH v2 1/1] " Nils-Christian Kempke
@ 2022-01-21 16:49 ` Andrew Burgess
2022-01-23 10:05 ` Joel Brobecker
0 siblings, 1 reply; 6+ messages in thread
From: Andrew Burgess @ 2022-01-21 16:49 UTC (permalink / raw)
To: Nils-Christian Kempke; +Cc: gdb-patches, brobecker
* Nils-Christian Kempke via Gdb-patches <gdb-patches@sourceware.org> [2022-01-17 12:30:05 +0100]:
> 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.
Thanks,
Andrew
> ---
> 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 d04fd0987e..6009cb65c5 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 ""
> }
>
> + # Normally, info symbol prints 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/decoder and decoded 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 is 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*] || [test_compiler_info intel*]} {
> + 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
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2 1/1] gdb, testsuite, fortran: adapt info symbol expected output for intel compilers
2022-01-21 16:49 ` Andrew Burgess
@ 2022-01-23 10:05 ` Joel Brobecker
2022-01-25 7:45 ` Kempke, Nils-Christian
0 siblings, 1 reply; 6+ messages in thread
From: Joel Brobecker @ 2022-01-23 10:05 UTC (permalink / raw)
To: Andrew Burgess; +Cc: Nils-Christian Kempke, gdb-patches, brobecker
> > 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: [PATCH v2 1/1] gdb, testsuite, fortran: adapt info symbol expected output for intel compilers
2022-01-23 10:05 ` Joel Brobecker
@ 2022-01-25 7:45 ` Kempke, Nils-Christian
2022-01-28 18:24 ` Tom Tromey
0 siblings, 1 reply; 6+ messages in thread
From: Kempke, Nils-Christian @ 2022-01-25 7:45 UTC (permalink / raw)
To: Joel Brobecker, Andrew Burgess; +Cc: gdb-patches
> -----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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2 1/1] gdb, testsuite, fortran: adapt info symbol expected output for intel compilers
2022-01-25 7:45 ` Kempke, Nils-Christian
@ 2022-01-28 18:24 ` Tom Tromey
0 siblings, 0 replies; 6+ messages in thread
From: Tom Tromey @ 2022-01-28 18:24 UTC (permalink / raw)
To: Kempke, Nils-Christian via Gdb-patches
Cc: Joel Brobecker, Andrew Burgess, Kempke, Nils-Christian
>> As I have neither a Sourceware account nor write access I'd kindly
>> ask one of you to push the patch on my behalf.
I've pushed this.
If you want write-after-approval access (recommended if you plan to
submit more patches), email me off-list.
Tom
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-01-28 18:24 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-17 11:30 [PATCH v2 0/1] gdb, testsuite, fortran: adapt info symbol expected output for intel compilers Nils-Christian Kempke
2022-01-17 11:30 ` [PATCH v2 1/1] " Nils-Christian Kempke
2022-01-21 16:49 ` Andrew Burgess
2022-01-23 10:05 ` Joel Brobecker
2022-01-25 7:45 ` Kempke, Nils-Christian
2022-01-28 18:24 ` Tom Tromey
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).