[RFC][PATCH 0/1] gdb, testsuite, fortran, ada: gfortran symbols get demangled as ada

[RFC][PATCH 0/1] gdb, testsuite, fortran, ada: gfortran symbols get demangled as ada

[Nils-Christian Kempke]

Hi,

the attached patch is a fix we used in our CI for enabling the
nested-funcs-2.exp test for the intel compilers.  We noticed some fails
there and, after investigating, found the following:

Apparently, when running info symbols on Fortran symbols generated by
gfortran the Ada demangler (called as the last of all demanglers)
recognizes those as Ada and demangles them.  We found this to be rather
unexpected and consider it a bug.  For now, we kept this behavior and just
applied the attached patch to the failing test.  There is even a comment
about the Ada demangler maybe demangling a bit too much in
ada-lang.c:sniff_from_mangled_name.  The comment reads "with a bit of bad
luck, we might be able to decode a non-Ada symbol, generating an incorrect
demangled name".
Considering the observed behavior the comment seem a bit trivializing.

The gfortran version used for this was GNU Fortran (Ubuntu
9.3.0-17ubuntu1~20.04) 9.3.0.
 
We wanted to collect some feedback on how to deal with this issue.  The
demangling of gfortran by ada-lang.c seems not to be harmful but to
actually improve readability.

Any feedback is highly appreciated.

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

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

[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 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'"

...

                === 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

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

[Joel Brobecker]

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_".

  - 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?)

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.

> 
> ...
> 
>                 === 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

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

[Kempke, Nils-Christian]

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