Debuginfo in gdb shows this pointer in 'info functions' command

[jerboaa]

Describe the issue
Since 87722a0 some no-arg methods show up to take an argument in gdb when they shouldn't. Example:

File debug_symbols_smoke/ClassA.java:
37:	java.lang.String *debug_symbols_smoke.ClassA::toString(debug_symbols_smoke.ClassA *);

File debug_symbols_smoke/Main.java:
	void debug_symbols_smoke.Main$$Lambda$814/0x00000007c092c418::accept(debug_symbols_smoke.Main$$Lambda$814/0x00000007c092c418 *, java.lang.Object *);
50:	void debug_symbols_smoke.Main::lambda$thisIsTheEnd$0(java.io.ByteArrayOutputStream *, debug_symbols_smoke.ClassA *);
64:	void debug_symbols_smoke.Main::main(java.lang.String[] *);
49:	void debug_symbols_smoke.Main::thisIsTheEnd(java.util.List *);

should be something like this:

File debug_symbols_smoke/ClassA.java:
37:	java.lang.String *debug_symbols_smoke.ClassA::toString(void);

File debug_symbols_smoke/Main.java:
	void debug_symbols_smoke.Main$$Lambda$814/0x00000007c092c418::accept(java.lang.Object *);
50:	void debug_symbols_smoke.Main::lambda$thisIsTheEnd$0(debug_symbols_smoke.ClassA *);
64:	void debug_symbols_smoke.Main::main(java.lang.String[] *);
49:	void debug_symbols_smoke.Main::thisIsTheEnd(java.util.List *);

Steps to reproduce the issue

1. git clone https://github.com/Karm/mandrel-integration-tests.git
2. cd mandrel-integration-tests/apps/debug-symbols-smoke
3. mvn clean package
4. native-image -g -jar target/debug-symbols-smoke.jar
5. gdb -ex 'set debuginfod enabled off' -ex 'set breakpoint pending on' -ex 'break main' -ex 'run' --args ./debug-symbols-smoke

GNU gdb (GDB) Fedora 12.1-1.fc36
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./debug-symbols-smoke...
Breakpoint 1 at 0x436940: main. (2 locations)
Starting program: /disk/graal/upstream-sources/mandrel-integration-tests/apps/debug-symbols-smoke/debug-symbols-smoke 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, com.oracle.svm.core.code.IsolateEnterStub::JavaMainWrapper_run_5087f5482cc9a6abc971913ece43acb471d2631b (__0=1, __1=0x7fffffffda88) at com/oracle/svm/core/code/IsolateEnterStub.java:1
1	/*
Missing separate debuginfos, use: dnf debuginfo-install glibc-2.35-17.fc36.x86_64 zlib-1.2.11-33.fc36.x86_64
(gdb) info functions .*smoke.*
All functions matching regular expression ".*smoke.*":

File debug_symbols_smoke/ClassA.java:
37:	java.lang.String *debug_symbols_smoke.ClassA::toString(debug_symbols_smoke.ClassA *);

File debug_symbols_smoke/Main.java:
	void debug_symbols_smoke.Main$$Lambda$814/0x00000007c092c418::accept(debug_symbols_smoke.Main$$Lambda$814/0x00000007c092c418 *, java.lang.Object *);
50:	void debug_symbols_smoke.Main::lambda$thisIsTheEnd$0(java.io.ByteArrayOutputStream *, debug_symbols_smoke.ClassA *);
64:	void debug_symbols_smoke.Main::main(java.lang.String[] *);
49:	void debug_symbols_smoke.Main::thisIsTheEnd(java.util.List *);
(gdb) quit

Describe GraalVM and your environment:

• GraalVM version: revision 3d56567 from master
• JDK major version: 17
• OS: Linux
• Architecture: AMD64

More details
Issue originally found here: Karm/mandrel-integration-tests#110

[adinn]

First off, I'll note that this problem has been fixed by PR #5172. Normally that would mean this issue can simply be closed without further action. However, since the bug also affects the latest supported release of GraalVM Native and Mandrel further explanation is needed to clarify what, if anything, can be done to remedy the problem in those releases.

TLDR

The options to fix this problem in these legacy releases are:

1. Backport PR [GR-41047] Use C++ symbol mangling on Linux to make tools happy #5172.
2. Remove commit 87722a0 and the rest of the perf support changes that accompanied it.
3. Alternatively, we can stick with the status quo

Explanation

The offending commit installs a linkage_name into the DWARF info for a method declaration in the format <classname>::<method_selector>. This ensures that gdb, perf and valgrind print recognizable method names in their output and connect them with the rest of the related DWARF info. Without this change perf and valgrind end up printing code addresses, making the output very hard to use.

For the most part this change ensures that gdb still employs the correct name for the method. However, in the case of gdb command info function <name_pattern> it causes a problem. This is caused by a detail of a routine in the implementation that is present to allow reuse of code for both C and C++.

The problematic routine constructs a function name for a C++ method or C function. In the former case, it expects to be passed a demangled name string derived from a (mangled) linkage_name attribute, this case being detected by looking for '(' in the name text. In the latter case, it expects to be passed a name string without an embedded '(', which it expects to have been read from the linkage_name attribute or, if that is not present, the name attribute.

In either case, the signature string is synthesized by processing the DWARF parameter type info (yes, even though it is present in the demangled C++ name). However, if the routine thinks this is a C function it does not suppress printing of the artificial first parameter this even though the parameter is clearly labelled artificial (a comment says that this is because some C compilers add this label -- it seems for reasons known only to the compiler author).

It is not really possible to fix this.

1. The only way to get gdb and the tools to consistently translate a linkage_name attribute to a correct C++ name is to mangle it using a BFD compatible mangling convention i.e. use the latest version of the perf support code.
2. The other alternative is to drop the linkage_name attribute, making perf and valgrind close to useless.
3. Finally, of course, we can live with the status quo where info functions <pattern> prints misleading information about arguments for instance methods.

[jerboaa]

@adinn OK, thanks. As this is fixed in master (23.0-dev) release I'll close it and open new issues downstream if we want to address the issue there.