[RFC] [gdb/testsuite] Use dwarf assembly in gdb.dlang/dlang-start.exp

[RFC] [gdb/testsuite] Use dwarf assembly in gdb.dlang/dlang-start.exp

[Tom de Vries]

For test-case gdb.dlang/dlang-start.exp, I run into:
...
gdb compile failed, default_target_compile: Can't find gdc.
...

AFAICT, my distro has no support for gdc, but I'd like to have the test-case
running and passing, so let's rewrite the test-case using dwarf assembly
(though arguably, it's not a bad idea to have test-cases excercising
actual compilers).

My distro does have a package providing dmd, so let's try out simple.d
compiled with dmd, and investigate what the start command does.

First of all, when compiled without debug info:
...
$ dmd src/gdb/testsuite/gdb.dlang/simple.d
...
we have:
...
$ gdb -q -batch simple -ex start
Temporary breakpoint 1 at 0x438448
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Temporary breakpoint 1, 0x0000000000438448 in D main ()
(gdb)
...

AFAICT, gdb uses "D main" because the minimal symbol _Dmain:
...
$ nm simple | grep 438448
0000000000438448 t
0000000000438448 W _Dmain
...
is demangled into "D main":
...
$ nm simple | grep 438448 | c++filt -s dlang
0000000000438448 t
0000000000438448 W D main
...

When we try with debug info:
...
$ dmd src/gdb/testsuite/gdb.dlang/simple.d -g
...
we get instead:
...
$ gdb -q -batch simple -ex start
Temporary breakpoint 1 at 0x43844e: file simple.d, line 17.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Temporary breakpoint 1, _Dmain () at simple.d:17
17      }
(gdb)
...

Hmm, now we use "_Dmain", I'm not sure why.  We have:
...
 <1><10a>: Abbrev Number: 3 (DW_TAG_subprogram)
    <10b>   DW_AT_name        : D main
    <112>   DW_AT_MIPS_linkage_name: _Dmain
...
so we could have used the DW_AT_name value "D main".

Mimicing this debug info in the dwarf assembly (without the line info) gets us
the same name:
...
(gdb) start ^M
Temporary breakpoint 1 at 0x4004ab^M
Starting program: outputs/gdb.dlang/dlang-start/dlang-start ^M
^M
Temporary breakpoint 1, 0x00000000004004ab in _Dmain ()^M
(gdb)
...

Also add a "show language" to check that we automatically set the language
correctly to D.

Note that the dwarf assembly also describes main, otherwise the test-case
doesn't function as regression test for commit 47fe57c9281 ("Fix "start" for
D, Rust, etc").

Tested on x86_64-linux.
---
 gdb/testsuite/gdb.dlang/dlang-start.exp | 56 +++++++++++++++++++++++--
 gdb/testsuite/gdb.dlang/dmain.c         | 31 ++++++++++++++
 2 files changed, 83 insertions(+), 4 deletions(-)
 create mode 100644 gdb/testsuite/gdb.dlang/dmain.c

diff --git a/gdb/testsuite/gdb.dlang/dlang-start.exp b/gdb/testsuite/gdb.dlang/dlang-start.exp
index fd4688b0635..a1ce92967f3 100644
--- a/gdb/testsuite/gdb.dlang/dlang-start.exp
+++ b/gdb/testsuite/gdb.dlang/dlang-start.exp
@@ -16,14 +16,60 @@
 # Test "start" for D.
 
 load_lib d-support.exp
-require allow_d_tests
+load_lib dwarf.exp
+require allow_d_tests dwarf2_support
 
 # This testcase verifies the behavior of the `start' command, which
 # does not work when we use the gdb stub...
 require !use_gdb_stub
 
-standard_testfile simple.d
-if {[prepare_for_testing "failed to prepare" $testfile $srcfile {debug d}]} {
+standard_testfile dmain.c -dw.S
+
+with_shared_gdb {
+    lassign [function_range _Dmain ${srcdir}/${subdir}/${srcfile}] \
+	dmain_start dmain_length
+
+    lassign [function_range main ${srcdir}/${subdir}/${srcfile}] \
+	main_start main_length
+}
+
+set asm_file [standard_output_file $srcfile2]
+Dwarf::assemble $asm_file {
+    global dmain_start dmain_length
+    global main_start main_length
+
+    cu { label cu_start } {
+	compile_unit {
+	    {language @DW_LANG_D}
+	} {
+	    module {
+		{name dmain}
+	    }
+	    subprogram {
+		{name "D main" }
+		{MIPS_linkage_name "_Dmain"}
+		{low_pc $dmain_start DW_FORM_addr}
+		{high_pc "$dmain_start + $dmain_length" DW_FORM_addr}
+		{external 1 flag_present}
+	    }
+	    subprogram {
+		{name "dmain._d_cmain!().main" }
+		{MIPS_linkage_name "main"}
+		{low_pc $main_start DW_FORM_addr}
+		{high_pc "$main_start + $main_length" DW_FORM_addr}
+		{external 1 flag_present}
+	    }
+	}
+    }
+
+    aranges {} cu_start {
+	arange {} $dmain_start $dmain_length
+	arange {} $main_start $main_length
+    }
+}
+
+if { [prepare_for_testing "failed to prepare" ${testfile} \
+	  [list $srcfile $asm_file] {nodebug}] } {
     return -1
 }
 
@@ -34,5 +80,7 @@ if {[gdb_start_cmd] < 0} {
 }
 
 gdb_test "" \
-    "main \\(\\) at .*simple.d.*" \
+    "in _Dmain \\(\\)" \
     "start"
+
+gdb_test "show language" {"auto; currently d".}
diff --git a/gdb/testsuite/gdb.dlang/dmain.c b/gdb/testsuite/gdb.dlang/dmain.c
new file mode 100644
index 00000000000..d4bded8a012
--- /dev/null
+++ b/gdb/testsuite/gdb.dlang/dmain.c
@@ -0,0 +1,31 @@
+/* Copyright 2023 Free Software Foundation, Inc.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 3 of the License, or
+   (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program.  If not, see <http://www.gnu.org/licenses/>.  */
+
+
+int
+_Dmain (void)
+{
+  asm ("_Dmain_label: .globl _Dmain_label");
+  return 0;
+}
+
+int
+main (void)
+{
+  asm ("main_label: .globl main_label");
+  int res = _Dmain ();
+
+  return res;
+}

base-commit: 868014341a7befe77468a87ef9d9da109cbf3c3c
-- 
2.35.3

Re: [RFC] [gdb/testsuite] Use dwarf assembly in gdb.dlang/dlang-start.exp

[Iain Buclaw]

Excerpts from Tom de Vries via Gdb-patches's message of Februar 20, 2023 2:48 pm:
> For test-case gdb.dlang/dlang-start.exp, I run into:
> ...
> gdb compile failed, default_target_compile: Can't find gdc.
> ...
> 
> AFAICT, my distro has no support for gdc, but I'd like to have the test-case
> running and passing, so let's rewrite the test-case using dwarf assembly
> (though arguably, it's not a bad idea to have test-cases excercising
> actual compilers).
> 
> My distro does have a package providing dmd, so let's try out simple.d
> compiled with dmd, and investigate what the start command does.
> 

I'm pretty sure I'd get testsuite failures for not having Ada or Rust
installed either.  Shouldn't the testsuite just return UNSUPPORTED when
there's a missing dependency?

> AFAICT, gdb uses "D main" because the minimal symbol _Dmain:
> ...
> $ nm simple | grep 438448
> 0000000000438448 t
> 0000000000438448 W _Dmain
> ...
> is demangled into "D main":
> ...

Yes. If I try to second guess my thinking from 2016 or so. I believe it
was because "_Dmain" could come from any language, but having a space in
the identifier pretty much guarantees only a D compiler generated it.

Iain.

Re: [RFC] [gdb/testsuite] Use dwarf assembly in gdb.dlang/dlang-start.exp

[Tom de Vries]

On 2/20/23 15:14, Iain Buclaw wrote:
> Excerpts from Tom de Vries via Gdb-patches's message of Februar 20, 2023 2:48 pm:
>> For test-case gdb.dlang/dlang-start.exp, I run into:
>> ...
>> gdb compile failed, default_target_compile: Can't find gdc.
>> ...
>>
>> AFAICT, my distro has no support for gdc, but I'd like to have the test-case
>> running and passing, so let's rewrite the test-case using dwarf assembly
>> (though arguably, it's not a bad idea to have test-cases excercising
>> actual compilers).
>>
>> My distro does have a package providing dmd, so let's try out simple.d
>> compiled with dmd, and investigate what the start command does.
>>
> 
> I'm pretty sure I'd get testsuite failures for not having Ada or Rust
> installed either. 

Yes, most likely.

> Shouldn't the testsuite just return UNSUPPORTED when
> there's a missing dependency?
> 

That's certainly an option.  OTOH, the approach taken in this patch is 
to instead eliminate the dependency, which ensures that everybody 
running the entire testsuite will exercise this test-case.

That sort of approach is not feasible for ada which has a lot of 
test-cases, and is not needed either (for me) for ada or rust because 
compilers are readily available in packages.

>> AFAICT, gdb uses "D main" because the minimal symbol _Dmain:
>> ...
>> $ nm simple | grep 438448
>> 0000000000438448 t
>> 0000000000438448 W _Dmain
>> ...
>> is demangled into "D main":
>> ...
> 
> Yes. If I try to second guess my thinking from 2016 or so. I believe it
> was because "_Dmain" could come from any language, but having a space in
> the identifier pretty much guarantees only a D compiler generated it.

I see, interesting, thanks for sharing that.

Thanks
- Tom

Re: [RFC] [gdb/testsuite] Use dwarf assembly in gdb.dlang/dlang-start.exp

[Tom de Vries]

On 2/20/23 14:48, Tom de Vries via Gdb-patches wrote:
>   so let's rewrite the test-case using dwarf assembly
> (though arguably, it's not a bad idea to have test-cases excercising
> actual compilers).

I ended up solving this conundrum by moving the dwarf assembly into a 
separate test-case ( 
https://sourceware.org/pipermail/gdb-patches/2023-March/198314.html ).

Thanks,
- Tom