[PATCH] Guard compile tests from running when unsupported + harden feature support check

[PATCH] Guard compile tests from running when unsupported + harden feature support check

[Luis Machado]

In our test environment i noticed a few compile tests, though unsupported,
were still being executed and causing spurious FAIL's.

The following change adds a missing feature support check to compile-ifunc.exp
and also adds one more pattern to the feature support check function.

With this change, none of the compile tests run when they're not supposed to.

OK?

gdb/testsuite/ChangeLog:

2015-08-19  Luis Machado  <lgustavo@codesourcery.com>

	* lib/gdb.exp (skip_compile_feature_tests): Check for unsupported
	compiler language.
	* gdb.compile/compile-ifunc.exp (with_test_prefix): Check feature
	support before running tests.
---
 gdb/testsuite/gdb.compile/compile-ifunc.exp | 5 +++++
 gdb/testsuite/lib/gdb.exp                   | 3 +++
 2 files changed, 8 insertions(+)

diff --git a/gdb/testsuite/gdb.compile/compile-ifunc.exp b/gdb/testsuite/gdb.compile/compile-ifunc.exp
index 026c62f..80d7bb4 100644
--- a/gdb/testsuite/gdb.compile/compile-ifunc.exp
+++ b/gdb/testsuite/gdb.compile/compile-ifunc.exp
@@ -46,6 +46,11 @@ with_test_prefix "debug" {
 	return -1
     }
 
+    if {[skip_compile_feature_tests]} {
+	untested "compile command not supported (could not find libcc1 shared library?)"
+	return -1
+    }
+
     # gnu_ifunc (10): error: too many arguments to function 'gnu_ifunc'
     gdb_test_no_output "compile code resultvar = gnu_ifunc_alias (10);"
 
diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index 56cde7a..fcf9cac 100644
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -3005,6 +3005,9 @@ proc skip_compile_feature_tests {} {
 	-re "Command not supported on this host\\..*\r\n$gdb_prompt $" {
 	    set result 1
 	}
+	-re "No compiler support for this language\\.\r\n$gdb_prompt $" {
+	    set result 1
+	}
 	-re "\r\n$gdb_prompt $" {
 	}
     }
-- 
1.9.1

Re: [PATCH] Guard compile tests from running when unsupported + harden feature support check

[Pedro Alves]

On 08/19/2015 01:53 PM, Luis Machado wrote:

> +    if {[skip_compile_feature_tests]} {
> +	untested "compile command not supported (could not find libcc1 shared library?)"
> +	return -1
> +    }
> +
>      # gnu_ifunc (10): error: too many arguments to function 'gnu_ifunc'
>      gdb_test_no_output "compile code resultvar = gnu_ifunc_alias (10);"
>  

This one's OK.

> diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
> index 56cde7a..fcf9cac 100644
> --- a/gdb/testsuite/lib/gdb.exp
> +++ b/gdb/testsuite/lib/gdb.exp
> @@ -3005,6 +3005,9 @@ proc skip_compile_feature_tests {} {
>  	-re "Command not supported on this host\\..*\r\n$gdb_prompt $" {
>  	    set result 1
>  	}
> +	-re "No compiler support for this language\\.\r\n$gdb_prompt $" {
> +	    set result 1
> +	}

This one I'm not so sure.

I'd suspect that that could happen when e.g., gdb connects to gdbserver and
finds the program stopped at the entry point, and then the current language
ends up set to asm instead of C.  But then that would be a test bug and it
would be wrong to skip further testing.

But please don't make us guess; please expand on when do you see this.

Thanks,
Pedro Alves

Re: [PATCH] Guard compile tests from running when unsupported + harden feature support check

[Luis Machado]

On 08/19/2015 10:15 AM, Pedro Alves wrote:
> On 08/19/2015 01:53 PM, Luis Machado wrote:
>
>> +    if {[skip_compile_feature_tests]} {
>> +	untested "compile command not supported (could not find libcc1 shared library?)"
>> +	return -1
>> +    }
>> +
>>       # gnu_ifunc (10): error: too many arguments to function 'gnu_ifunc'
>>       gdb_test_no_output "compile code resultvar = gnu_ifunc_alias (10);"
>>
>
> This one's OK.
>
>> diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
>> index 56cde7a..fcf9cac 100644
>> --- a/gdb/testsuite/lib/gdb.exp
>> +++ b/gdb/testsuite/lib/gdb.exp
>> @@ -3005,6 +3005,9 @@ proc skip_compile_feature_tests {} {
>>   	-re "Command not supported on this host\\..*\r\n$gdb_prompt $" {
>>   	    set result 1
>>   	}
>> +	-re "No compiler support for this language\\.\r\n$gdb_prompt $" {
>> +	    set result 1
>> +	}
>
> This one I'm not so sure.
>
> I'd suspect that that could happen when e.g., gdb connects to gdbserver and
> finds the program stopped at the entry point, and then the current language
> ends up set to asm instead of C.  But then that would be a test bug and it
> would be wrong to skip further testing.
>

No stopping at the entry point, we run to main.

> But please don't make us guess; please expand on when do you see this.

It is related to how the binaries are built, without debug info. That's 
how GDB reacts to these GCC 5.2-produced binaries.

compile-ifunc.exp:

#0  0x100007b0 in main ()
(gdb) show language
show language
The current source language is "auto; currently asm".

compile-ops.exp:

Breakpoint 1, 0x10000724 in func (param=268503652, 
optimized_out=<optimized out>)^M
(gdb) compile code -- ;^M
No compiler support for this language.^M

show language
The current source language is "auto; currently asm".

Enabling debug info i see the standard error about missing libcc1, which 
may be an alternate fix, though checking for unsupported languages does 
sound useful to me.

Re: [PATCH] Guard compile tests from running when unsupported + harden feature support check

[Pedro Alves]

On 08/19/2015 02:34 PM, Luis Machado wrote:

>> But please don't make us guess; please expand on when do you see this.
> 
> It is related to how the binaries are built, without debug info. That's 
> how GDB reacts to these GCC 5.2-produced binaries.
> 

...

> 
> Enabling debug info i see the standard error about missing libcc1, which 
> may be an alternate fix, though checking for unsupported languages does 
> sound useful to me.

I disagree.  It's a bug, because the tests are testing C code.

> compile-ifunc.exp:
>
> #0  0x100007b0 in main ()
> (gdb) show language
> show language
> The current source language is "auto; currently asm".
>

This binary has no debug info (by test design), so we should just
make the test do "set language c" (with a comment).

> compile-ops.exp:
>
> Breakpoint 1, 0x10000724 in func (param=268503652,
> optimized_out=<optimized out>)^M
> (gdb) compile code -- ;^M
> No compiler support for this language.^M
>
> show language
> The current source language is "auto; currently asm".

This one looks like a gdb bug?  AFAICS, the test generates
debug info, and gdb should have figured out the language is c.
At least, from skimming the test's .exp, I see:

	compile_unit {
	    {name file1.txt}
	    {language @DW_LANG_C}
             ^^^^^^^^^^^^^^^^^^^
	    {low_pc func_start addr}
	    {high_pc func_end addr}
	} {
	    global program


BTW, it'd be nice if the "No compiler support for this language"
error told us which language is "this"...

Thanks,
Pedro Alves

Re: [PATCH] Guard compile tests from running when unsupported + harden feature support check

[Luis Machado]

On 08/19/2015 10:45 AM, Pedro Alves wrote:
> On 08/19/2015 02:34 PM, Luis Machado wrote:
>> Enabling debug info i see the standard error about missing libcc1, which
>> may be an alternate fix, though checking for unsupported languages does
>> sound useful to me.
>
> I disagree.  It's a bug, because the tests are testing C code.
>

I did a bit more investigation and here's what i found:

GDB generally sets the default language to C on top.c:gdb_init. Usually 
the dynamic loader code is not available, so GDB doesn't switch away 
from C when connecting to GDBserver.

It does for me because it sees real asm code from the dynamic loader, so 
the starting language is "asm". Now, the testcases have different behaviors.

For compile-ifunc.exp, when we run to main, we don't have any kind of 
debug info that tells GDB what language we are dealing with, so GDB 
doesn't switch away from the previously selected "asm". Forcing the 
language to C would fix this.

For compile-ops.exp, on the other hand, we run to "func" and it has 
debug info, but the source file is named "file1.txt". Not sure if this 
was on purpose, but it seems to throw GDB off when trying to find the 
source language, even though the DIE states it is C.

If i rename the source file to file1.c, then GDB correctly selects C as 
the current source language.

It could be either a GDB bug for not honoring the language in the DIE 
itself or a testcase issue for not naming the source file with the 
correct language extension.

> BTW, it'd be nice if the "No compiler support for this language"
> error told us which language is "this"...
>

Indeed it would be useful.

[PATCH] Fix language of compilation unit with unknown file extension (Re: [PATCH] Guard compile tests from running when unsupported + harden feature support check)

[Pedro Alves]

[+Doug]

On 08/19/2015 07:01 PM, Luis Machado wrote:

> It does for me because it sees real asm code from the dynamic loader, so 
> the starting language is "asm". Now, the testcases have different behaviors.

Right, that's what I suspected before.

> For compile-ifunc.exp, when we run to main, we don't have any kind of 
> debug info that tells GDB what language we are dealing with, so GDB 
> doesn't switch away from the previously selected "asm". Forcing the 
> language to C would fix this.

That's what we should do.

> For compile-ops.exp, on the other hand, we run to "func" and it has 
> debug info, but the source file is named "file1.txt". Not sure if this 
> was on purpose, but it seems to throw GDB off when trying to find the 
> source language, even though the DIE states it is C.
> 
> If i rename the source file to file1.c, then GDB correctly selects C as 
> the current source language.
> 
> It could be either a GDB bug for not honoring the language in the DIE 
> itself or a testcase issue for not naming the source file with the 
> correct language extension.

I think it's a GDB bug.  See patch below.

From de0b09c8cd24018c11df03a501b2e058727e1abc Mon Sep 17 00:00:00 2001
From: Pedro Alves <palves@redhat.com>
Date: Wed, 19 Aug 2015 20:52:44 +0100
Subject: [PATCH] Fix language of compilation unit with unknown file extension

Here, in dwarfread.c:process_full_comp_unit:

      /* Set symtab language to language from DW_AT_language.  If the
	 compilation is from a C file generated by language preprocessors, do
	 not set the language if it was already deduced by start_subfile.  */
      if (!(cu->language == language_c
	    && COMPUNIT_FILETABS (cust)->language != language_c))
	COMPUNIT_FILETABS (cust)->language = cu->language;

in case start_subfile doesn't manage to deduce a language
COMPUNIT_FILETABS(cust)->language ends up as language_unknown, not
language_c.  So the condition above evals false and we never set the
language from the cu's language.

gdb/ChangeLog:
2015-08-19  Pedro Alves  <palves@redhat.com>

	* dwarf2read.c (process_full_comp_unit): To tell whether
	start_subfile managed to deduce a language, test for
	language_unknown instead of language_c.

gdb/testsuite/ChangeLog:
2015-08-19  Pedro Alves  <palves@redhat.com>

	* gdb.dwarf2/comp-unit-lang.exp: New file.
	* gdb.dwarf2/comp-unit-lang.c: New file.
---
 gdb/dwarf2read.c                            |  2 +-
 gdb/testsuite/gdb.dwarf2/comp-unit-lang.c   | 34 +++++++++++
 gdb/testsuite/gdb.dwarf2/comp-unit-lang.exp | 91 +++++++++++++++++++++++++++++
 3 files changed, 126 insertions(+), 1 deletion(-)
 create mode 100644 gdb/testsuite/gdb.dwarf2/comp-unit-lang.c
 create mode 100644 gdb/testsuite/gdb.dwarf2/comp-unit-lang.exp

diff --git a/gdb/dwarf2read.c b/gdb/dwarf2read.c
index 445ad86..92b3982 100644
--- a/gdb/dwarf2read.c
+++ b/gdb/dwarf2read.c
@@ -8079,7 +8079,7 @@ process_full_comp_unit (struct dwarf2_per_cu_data *per_cu,
 	 compilation is from a C file generated by language preprocessors, do
 	 not set the language if it was already deduced by start_subfile.  */
       if (!(cu->language == language_c
-	    && COMPUNIT_FILETABS (cust)->language != language_c))
+	    && COMPUNIT_FILETABS (cust)->language != language_unknown))
 	COMPUNIT_FILETABS (cust)->language = cu->language;
 
       /* GCC-4.0 has started to support -fvar-tracking.  GCC-3.x still can
diff --git a/gdb/testsuite/gdb.dwarf2/comp-unit-lang.c b/gdb/testsuite/gdb.dwarf2/comp-unit-lang.c
new file mode 100644
index 0000000..2835209
--- /dev/null
+++ b/gdb/testsuite/gdb.dwarf2/comp-unit-lang.c
@@ -0,0 +1,34 @@
+/* This testcase is part of GDB, the GNU debugger.
+
+   Copyright 2011-2015 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/>.  */
+
+asm (".section	\".text\"");
+asm (".balign 8");
+asm ("func_start: .globl func_start");
+
+static void
+func (void)
+{
+}
+
+asm ("func_end: .globl func_end");
+
+int
+main (void)
+{
+  func ();
+  return 0;
+}
diff --git a/gdb/testsuite/gdb.dwarf2/comp-unit-lang.exp b/gdb/testsuite/gdb.dwarf2/comp-unit-lang.exp
new file mode 100644
index 0000000..b957cbd
--- /dev/null
+++ b/gdb/testsuite/gdb.dwarf2/comp-unit-lang.exp
@@ -0,0 +1,91 @@
+# Copyright 2014-2015 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/>.
+
+# Test that GDB determines the frame's language based on the comp
+# unit's language, even if the file has an unknown file extension,
+# such as ".txt".
+
+load_lib dwarf.exp
+
+# This test can only be run on targets which support DWARF-2 and use
+# gas.
+if {![dwarf2_support]} {
+    return 0
+}
+
+standard_testfile .c comp-unit-lang.S
+
+# Assemble the DWARF using CU_LANG as compilation unit's language.
+# Run to a function in that compilation unit and check that GDB
+# figures out that the language is GDB_LANG.
+
+proc do_test {cu_lang gdb_lang} {
+    global testfile srcfile srcfile2
+
+    global lang
+    set lang $cu_lang
+
+    # Make some DWARF for the test.
+    set asm_file [standard_output_file $srcfile2]
+    Dwarf::assemble $asm_file {
+	# Creating a CU with 4-byte addresses lets this test link on
+	# both 32- and 64-bit machines.
+	cu { addr_size 4 } {
+
+	    declare_labels int_label
+	    extern func_start func_end ptr
+
+	    global lang
+
+	    compile_unit {
+		{name file1.txt}
+		{language @$lang}
+		{low_pc func_start addr}
+		{high_pc func_end addr}
+	    } {
+		int_label: base_type {
+		    {name int}
+		    {byte_size 4 sdata}
+		    {encoding @DW_ATE_signed}
+		}
+
+		subprogram {
+		    {external 1 flag}
+		    {name func}
+		    {low_pc func_start addr}
+		    {high_pc func_end addr}
+		} {
+		}
+	    }
+	}
+    }
+
+    if { [prepare_for_testing "failed to prepare" ${testfile} \
+	      [list $srcfile $asm_file] {nodebug}] } {
+	return -1
+    }
+
+    if ![runto func] {
+	return -1
+    }
+
+    gdb_test "show language" "\"auto; currently $gdb_lang\".*"
+}
+
+# Some paths in the debugger that built-in fallbacks to C.  Check C++
+# as well to make sure the test doesn't happen to work because of such
+# a fallback.
+do_test DW_LANG_C "c"
+do_test DW_LANG_C_plus_plus "c\\+\\+"
-- 
1.9.3

Re: [PATCH] Fix language of compilation unit with unknown file extension (Re: [PATCH] Guard compile tests from running when unsupported + harden feature support check)

[Pedro Alves]

On 08/19/2015 08:57 PM, Pedro Alves wrote:
> On 08/19/2015 07:01 PM, Luis Machado wrote:
>> It could be either a GDB bug for not honoring the language in the DIE 
>> itself or a testcase issue for not naming the source file with the 
>> correct language extension.
> 
> I think it's a GDB bug.  See patch below.

I had left some unnecessary bits in the test's assembly (copy/paste, and
then insufficient trimming).  Here's a leaner version.

---
From 8451d7202d4126bfaec5a49fe555989b6fd9b2b1 Mon Sep 17 00:00:00 2001
From: Pedro Alves <palves@redhat.com>
Date: Wed, 19 Aug 2015 20:52:44 +0100
Subject: [PATCH] Fix language of compilation unit with unknown file extension

Here, in dwarfread.c:process_full_comp_unit:

      /* Set symtab language to language from DW_AT_language.  If the
	 compilation is from a C file generated by language preprocessors, do
	 not set the language if it was already deduced by start_subfile.  */
      if (!(cu->language == language_c
	    && COMPUNIT_FILETABS (cust)->language != language_c))
	COMPUNIT_FILETABS (cust)->language = cu->language;

in case start_subfile doesn't manage to deduce a language
COMPUNIT_FILETABS(cust)->language ends up as language_unknown, not
language_c.  So the condition above evals false and we never set the
language from the cu's language.

gdb/ChangeLog:
2015-08-19  Pedro Alves  <palves@redhat.com>

	* dwarf2read.c (process_full_comp_unit): To tell whether
	start_subfile managed to deduce a language, test for
	language_unknown instead of language_c.

gdb/testsuite/ChangeLog:
2015-08-19  Pedro Alves  <palves@redhat.com>

	* gdb.dwarf2/comp-unit-lang.exp: New file.
	* gdb.dwarf2/comp-unit-lang.c: New file.
---
 gdb/dwarf2read.c                            |  2 +-
 gdb/testsuite/gdb.dwarf2/comp-unit-lang.c   | 34 ++++++++++++
 gdb/testsuite/gdb.dwarf2/comp-unit-lang.exp | 83 +++++++++++++++++++++++++++++
 3 files changed, 118 insertions(+), 1 deletion(-)
 create mode 100644 gdb/testsuite/gdb.dwarf2/comp-unit-lang.c
 create mode 100644 gdb/testsuite/gdb.dwarf2/comp-unit-lang.exp

diff --git a/gdb/dwarf2read.c b/gdb/dwarf2read.c
index 445ad86..92b3982 100644
--- a/gdb/dwarf2read.c
+++ b/gdb/dwarf2read.c
@@ -8079,7 +8079,7 @@ process_full_comp_unit (struct dwarf2_per_cu_data *per_cu,
 	 compilation is from a C file generated by language preprocessors, do
 	 not set the language if it was already deduced by start_subfile.  */
       if (!(cu->language == language_c
-	    && COMPUNIT_FILETABS (cust)->language != language_c))
+	    && COMPUNIT_FILETABS (cust)->language != language_unknown))
 	COMPUNIT_FILETABS (cust)->language = cu->language;
 
       /* GCC-4.0 has started to support -fvar-tracking.  GCC-3.x still can
diff --git a/gdb/testsuite/gdb.dwarf2/comp-unit-lang.c b/gdb/testsuite/gdb.dwarf2/comp-unit-lang.c
new file mode 100644
index 0000000..2835209
--- /dev/null
+++ b/gdb/testsuite/gdb.dwarf2/comp-unit-lang.c
@@ -0,0 +1,34 @@
+/* This testcase is part of GDB, the GNU debugger.
+
+   Copyright 2011-2015 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/>.  */
+
+asm (".section	\".text\"");
+asm (".balign 8");
+asm ("func_start: .globl func_start");
+
+static void
+func (void)
+{
+}
+
+asm ("func_end: .globl func_end");
+
+int
+main (void)
+{
+  func ();
+  return 0;
+}
diff --git a/gdb/testsuite/gdb.dwarf2/comp-unit-lang.exp b/gdb/testsuite/gdb.dwarf2/comp-unit-lang.exp
new file mode 100644
index 0000000..9140608
--- /dev/null
+++ b/gdb/testsuite/gdb.dwarf2/comp-unit-lang.exp
@@ -0,0 +1,83 @@
+# Copyright 2014-2015 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/>.
+
+# Test that GDB determines the frame's language based on the comp
+# unit's language, even if the file has an unknown file extension,
+# such as ".txt".
+
+load_lib dwarf.exp
+
+# This test can only be run on targets which support DWARF-2 and use
+# gas.
+if {![dwarf2_support]} {
+    return 0
+}
+
+standard_testfile .c comp-unit-lang.S
+
+# Assemble the DWARF using CU_LANG as compilation unit's language.
+# Run to a function in that compilation unit and check that GDB
+# figures out that the language is GDB_LANG.
+
+proc do_test {cu_lang gdb_lang} {
+    global testfile srcfile srcfile2
+
+    global lang
+    set lang $cu_lang
+
+    # Make some DWARF for the test.
+    set asm_file [standard_output_file $srcfile2]
+    Dwarf::assemble $asm_file {
+	# Creating a CU with 4-byte addresses lets this test link on
+	# both 32- and 64-bit machines.
+	cu { addr_size 4 } {
+	    extern func_start func_end
+
+	    global lang
+
+	    compile_unit {
+		{name file1.txt}
+		{language @$lang}
+		{low_pc func_start addr}
+		{high_pc func_end addr}
+	    } {
+		subprogram {
+		    {external 1 flag}
+		    {name func}
+		    {low_pc func_start addr}
+		    {high_pc func_end addr}
+		} {
+		}
+	    }
+	}
+    }
+
+    if { [prepare_for_testing "failed to prepare" ${testfile} \
+	      [list $srcfile $asm_file] {nodebug}] } {
+	return -1
+    }
+
+    if ![runto func] {
+	return -1
+    }
+
+    gdb_test "show language" "\"auto; currently $gdb_lang\".*"
+}
+
+# Some paths in the debugger that built-in fallbacks to C.  Check C++
+# as well to make sure the test doesn't happen to work because of such
+# a fallback.
+do_test DW_LANG_C "c"
+do_test DW_LANG_C_plus_plus "c\\+\\+"
-- 
1.9.3

Re: [PATCH] Fix language of compilation unit with unknown file extension (Re: [PATCH] Guard compile tests from running when unsupported + harden feature support check)

[Doug Evans]

On Wed, Aug 19, 2015 at 1:02 PM, Pedro Alves <palves@redhat.com> wrote:
> On 08/19/2015 08:57 PM, Pedro Alves wrote:
>> On 08/19/2015 07:01 PM, Luis Machado wrote:
>>> It could be either a GDB bug for not honoring the language in the DIE
>>> itself or a testcase issue for not naming the source file with the
>>> correct language extension.
>>
>> I think it's a GDB bug.  See patch below.
>
> I had left some unnecessary bits in the test's assembly (copy/paste, and
> then insufficient trimming).  Here's a leaner version.
>
> ---
> From 8451d7202d4126bfaec5a49fe555989b6fd9b2b1 Mon Sep 17 00:00:00 2001
> From: Pedro Alves <palves@redhat.com>
> Date: Wed, 19 Aug 2015 20:52:44 +0100
> Subject: [PATCH] Fix language of compilation unit with unknown file extension
>
> Here, in dwarfread.c:process_full_comp_unit:
>
>       /* Set symtab language to language from DW_AT_language.  If the
>          compilation is from a C file generated by language preprocessors, do
>          not set the language if it was already deduced by start_subfile.  */
>       if (!(cu->language == language_c
>             && COMPUNIT_FILETABS (cust)->language != language_c))
>         COMPUNIT_FILETABS (cust)->language = cu->language;
>
> in case start_subfile doesn't manage to deduce a language
> COMPUNIT_FILETABS(cust)->language ends up as language_unknown, not
> language_c.  So the condition above evals false and we never set the
> language from the cu's language.
>
> gdb/ChangeLog:
> 2015-08-19  Pedro Alves  <palves@redhat.com>
>
>         * dwarf2read.c (process_full_comp_unit): To tell whether
>         start_subfile managed to deduce a language, test for
>         language_unknown instead of language_c.
>
> gdb/testsuite/ChangeLog:
> 2015-08-19  Pedro Alves  <palves@redhat.com>
>
>         * gdb.dwarf2/comp-unit-lang.exp: New file.
>         * gdb.dwarf2/comp-unit-lang.c: New file.

LGTM.

I'm assuming the "global lang" in the test is necessary.
Didn't verify it though.

Re: [PATCH] Fix language of compilation unit with unknown file extension (Re: [PATCH] Guard compile tests from running when unsupported + harden feature support check)

[Pedro Alves]

On 08/19/2015 09:42 PM, Doug Evans wrote:

> LGTM.
> 

> I'm assuming the "global lang" in the test is necessary.
> Didn't verify it though.

Hmm, yes, we need to do something as Dwarf::assemble doesn't
uplevel, but upvar is better than global.  Actually, I see it's
what other Dwarf tests use as well.  Here's what I pushed.

----------
From 40e3ad0ebb0c71008b928d6d350e9258dc1dcf2a Mon Sep 17 00:00:00 2001
From: Pedro Alves <palves@redhat.com>
Date: Thu, 20 Aug 2015 12:30:08 +0100
Subject: [PATCH] Fix language of compilation unit with unknown file extension

Here, in dwarfread.c:process_full_comp_unit:

      /* Set symtab language to language from DW_AT_language.  If the
	 compilation is from a C file generated by language preprocessors, do
	 not set the language if it was already deduced by start_subfile.  */
      if (!(cu->language == language_c
	    && COMPUNIT_FILETABS (cust)->language != language_c))
	COMPUNIT_FILETABS (cust)->language = cu->language;

in case start_subfile doesn't manage to deduce a language
COMPUNIT_FILETABS(cust)->language ends up as language_unknown, not
language_c.  So the condition above evals false and we never set the
language from the cu's language.

gdb/ChangeLog:
2015-08-20  Pedro Alves  <palves@redhat.com>

	* dwarf2read.c (process_full_comp_unit): To tell whether
	start_subfile managed to deduce a language, test for
	language_unknown instead of language_c.

gdb/testsuite/ChangeLog:
2015-08-20  Pedro Alves  <palves@redhat.com>

	* gdb.dwarf2/comp-unit-lang.exp: New file.
	* gdb.dwarf2/comp-unit-lang.c: New file.
---
 gdb/ChangeLog                               |  6 +++
 gdb/testsuite/ChangeLog                     |  5 ++
 gdb/dwarf2read.c                            |  2 +-
 gdb/testsuite/gdb.dwarf2/comp-unit-lang.c   | 34 ++++++++++++
 gdb/testsuite/gdb.dwarf2/comp-unit-lang.exp | 80 +++++++++++++++++++++++++++++
 5 files changed, 126 insertions(+), 1 deletion(-)
 create mode 100644 gdb/testsuite/gdb.dwarf2/comp-unit-lang.c
 create mode 100644 gdb/testsuite/gdb.dwarf2/comp-unit-lang.exp

diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index a9092cc..ed93dd2 100644
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,3 +1,9 @@
+2015-08-20  Pedro Alves  <palves@redhat.com>
+
+	* dwarf2read.c (process_full_comp_unit): To tell whether
+	start_subfile managed to deduce a language, test for
+	language_unknown instead of language_c.
+
 2015-08-20  Pierre-Marie de Rodat  <derodat@adacore.com>
 
 	* ada-lex.l: Reset the start condition to INITIAL in the rule that
diff --git a/gdb/testsuite/ChangeLog b/gdb/testsuite/ChangeLog
index 2fecd36..49ea9fb 100644
--- a/gdb/testsuite/ChangeLog
+++ b/gdb/testsuite/ChangeLog
@@ -1,3 +1,8 @@
+2015-08-20  Pedro Alves  <palves@redhat.com>
+
+	* gdb.dwarf2/comp-unit-lang.exp: New file.
+	* gdb.dwarf2/comp-unit-lang.c: New file.
+
 2015-08-20  Pierre-Marie de Rodat  <derodat@adacore.com>
 
 	* gdb.ada/attr_ref_and_charlit.exp: New testcase.
diff --git a/gdb/dwarf2read.c b/gdb/dwarf2read.c
index 4cf0a44..0c61df7 100644
--- a/gdb/dwarf2read.c
+++ b/gdb/dwarf2read.c
@@ -8072,7 +8072,7 @@ process_full_comp_unit (struct dwarf2_per_cu_data *per_cu,
 	 compilation is from a C file generated by language preprocessors, do
 	 not set the language if it was already deduced by start_subfile.  */
       if (!(cu->language == language_c
-	    && COMPUNIT_FILETABS (cust)->language != language_c))
+	    && COMPUNIT_FILETABS (cust)->language != language_unknown))
 	COMPUNIT_FILETABS (cust)->language = cu->language;
 
       /* GCC-4.0 has started to support -fvar-tracking.  GCC-3.x still can
diff --git a/gdb/testsuite/gdb.dwarf2/comp-unit-lang.c b/gdb/testsuite/gdb.dwarf2/comp-unit-lang.c
new file mode 100644
index 0000000..2835209
--- /dev/null
+++ b/gdb/testsuite/gdb.dwarf2/comp-unit-lang.c
@@ -0,0 +1,34 @@
+/* This testcase is part of GDB, the GNU debugger.
+
+   Copyright 2011-2015 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/>.  */
+
+asm (".section	\".text\"");
+asm (".balign 8");
+asm ("func_start: .globl func_start");
+
+static void
+func (void)
+{
+}
+
+asm ("func_end: .globl func_end");
+
+int
+main (void)
+{
+  func ();
+  return 0;
+}
diff --git a/gdb/testsuite/gdb.dwarf2/comp-unit-lang.exp b/gdb/testsuite/gdb.dwarf2/comp-unit-lang.exp
new file mode 100644
index 0000000..aec5582
--- /dev/null
+++ b/gdb/testsuite/gdb.dwarf2/comp-unit-lang.exp
@@ -0,0 +1,80 @@
+# Copyright 2014-2015 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/>.
+
+# Test that GDB determines the frame's language based on the comp
+# unit's language, even if the file has an unknown file extension,
+# such as ".txt".
+
+load_lib dwarf.exp
+
+# This test can only be run on targets which support DWARF-2 and use
+# gas.
+if {![dwarf2_support]} {
+    return 0
+}
+
+standard_testfile .c comp-unit-lang.S
+
+# Assemble the DWARF using CU_LANG as compilation unit's language.
+# Run to a function in that compilation unit and check that GDB
+# figures out that the language is GDB_LANG.
+
+proc do_test {cu_lang gdb_lang} {
+    global testfile srcfile srcfile2
+
+    # Make some DWARF for the test.
+    set asm_file [standard_output_file $srcfile2]
+    Dwarf::assemble $asm_file {
+	upvar cu_lang cu_lang
+
+	# Creating a CU with 4-byte addresses lets this test link on
+	# both 32- and 64-bit machines.
+	cu { addr_size 4 } {
+	    extern func_start func_end
+
+	    compile_unit {
+		{name file1.txt}
+		{language @$cu_lang}
+		{low_pc func_start addr}
+		{high_pc func_end addr}
+	    } {
+		subprogram {
+		    {external 1 flag}
+		    {name func}
+		    {low_pc func_start addr}
+		    {high_pc func_end addr}
+		} {
+		}
+	    }
+	}
+    }
+
+    if { [prepare_for_testing "failed to prepare" ${testfile} \
+	      [list $srcfile $asm_file] {nodebug}] } {
+	return -1
+    }
+
+    if ![runto func] {
+	return -1
+    }
+
+    gdb_test "show language" "\"auto; currently $gdb_lang\".*"
+}
+
+# Some paths in the debugger fall back to C.  Check C++ as well to
+# make sure the test doesn't happen to work because of such a
+# fallback.
+do_test DW_LANG_C "c"
+do_test DW_LANG_C_plus_plus "c\\+\\+"
-- 
1.9.3

Re: [PATCH] Guard compile tests from running when unsupported + harden feature support check

[Luis Machado]

[-- Attachment #1: Type: text/plain, Size: 291 bytes --]

On 08/19/2015 10:45 AM, Pedro Alves wrote:
> On 08/19/2015 02:34 PM, Luis Machado wrote:
>
> This binary has no debug info (by test design), so we should just
> make the test do "set language c" (with a comment).
>

Here's what i pushed for this one.

I see no further gdb.compile failures.

[-- Attachment #2: compile.diff --]
[-- Type: text/x-patch, Size: 2043 bytes --]

commit 8ce74153537add5e364865518a72194ab58b3dbc
Author: Luis Machado <lgustavo@codesourcery.com>
Date:   Thu Aug 27 01:49:05 2015 -0300

    Force language to C in gdb.compile/compile-ifunc.exp
    
    Due to the lack of debug information in the binary, GDB is unable to figure
    out what language is being used.  This may be a problem when doing remote
    debugging and the binary stops at the entry point containing asm code.
    
    In this case GDB will switch to asm as current language and will not switch
    back to C when it reaches main, which in turn causes the compile feature check
    to malfunction.
    
    This is solved by forcing the language to C after reaching main.
    
    gdb/testsuite/ChangeLog:
    
    2015-08-26  Luis Machado  <lgustavo@codesourcery.com>
    
    	* gdb.compile/compile-ifunc.exp (with_test_prefix): Force language
    	to C.

diff --git a/gdb/testsuite/ChangeLog b/gdb/testsuite/ChangeLog
index 5bba9d7..7b271e2 100644
--- a/gdb/testsuite/ChangeLog
+++ b/gdb/testsuite/ChangeLog
@@ -1,3 +1,8 @@
+2015-08-26  Luis Machado  <lgustavo@codesourcery.com>
+
+	* gdb.compile/compile-ifunc.exp (with_test_prefix): Force language
+	to C.
+
 2015-08-26  Patrick Palka  <patrick@parcs.ath.cx>
 
 	* gdb.base/run-after-attach.exp: New test file.
diff --git a/gdb/testsuite/gdb.compile/compile-ifunc.exp b/gdb/testsuite/gdb.compile/compile-ifunc.exp
index 026c62f..3a96552 100644
--- a/gdb/testsuite/gdb.compile/compile-ifunc.exp
+++ b/gdb/testsuite/gdb.compile/compile-ifunc.exp
@@ -25,6 +25,12 @@ with_test_prefix "nodebug" {
 	return -1
     }
 
+    # This binary has no debug information, so force the language to C in case
+    # GDB happened to see real asm code when it stopped at the entry point
+    # when talking to a remote target, like gdbserver.  This guarantees the
+    # feature check below will work.
+    gdb_test_no_output "set language c" ""
+
     if {[skip_compile_feature_tests]} {
 	untested "compile command not supported (could not find libcc1 shared library?)"
 	return -1