[PATCH] Run gdb.compile/*.exp on {x86,x86_64,s390}-linux only

[PATCH] Run gdb.compile/*.exp on {x86,x86_64,s390}-linux only

[Yao Qi]

I see many gdb.compile/*.exp fails on aarch64-linux and arm-linux,

(gdb) compile code -- ;
Could not find a compiler matching "^arm(-[^-]*)?-linux(-gnu)?-gcc$"
(gdb) compile code -- ;
aarch64-none-linux-gnu-gcc: error: unrecognized command line option '-m64'

I think we need to properly skip tests on targets which don't support
compile.  As far as I know, gdb compile is supported on x86, x86_64,
and s390.

This patch matches the target triplet in
lib/gdb.exp:skip_compile_feature_tests.  If the target triplet is
*not* x86,x86_64, and s390 linux, return 1; otherwise, do the
"compile code -- ;" test.

An alternative approach is to modify lib/gdb.exp:skip_compile_feature_tests
to match these error messages above.  However, these error message is
from libcc1, subject to change, and other targets may have different
error messages from libcc1.

gdb/testsuite:

2018-01-16  Yao Qi  <yao.qi@linaro.org>

	* lib/gdb.exp (skip_compile_feature_tests): Return 1 if target
	triplet isn't x86-linux or s390-linux.
---
 gdb/testsuite/lib/gdb.exp | 25 +++++++++++++++++--------
 1 file changed, 17 insertions(+), 8 deletions(-)

diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index a4bde72..8723925 100644
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -3141,16 +3141,25 @@ proc skip_compile_feature_tests {} {
     global gdb_prompt
 
     set result 0
-    gdb_test_multiple "compile code -- ;" "check for working compile command" {
-	"Could not load libcc1.*\r\n$gdb_prompt $" {
-	    set result 1
-	}
-	-re "Command not supported on this host\\..*\r\n$gdb_prompt $" {
-	    set result 1
-	}
-	-re "\r\n$gdb_prompt $" {
+
+    if { [istarget "i\[34567\]86-*-linux*"]
+	 || [istarget "x86_64-*-linux*"]
+	 || [istarget "s390*-*-linux*"] } {
+	gdb_test_multiple "compile code -- ;" \
+	    "check for working compile command" {
+	    "Could not load libcc1.*\r\n$gdb_prompt $" {
+		set result 1
+	    }
+	    -re "Command not supported on this host\\..*\r\n$gdb_prompt $" {
+		set result 1
+	    }
+	    -re "\r\n$gdb_prompt $" {
+	    }
 	}
+    } else {
+	set result 1
     }
+
     return $result
 }
 
-- 
1.9.1

Re: [PATCH] Run gdb.compile/*.exp on {x86,x86_64,s390}-linux only

[Pedro Alves]

On 01/16/2018 11:50 AM, Yao Qi wrote:
> I see many gdb.compile/*.exp fails on aarch64-linux and arm-linux,
> 
> (gdb) compile code -- ;
> Could not find a compiler matching "^arm(-[^-]*)?-linux(-gnu)?-gcc$"
> (gdb) compile code -- ;
> aarch64-none-linux-gnu-gcc: error: unrecognized command line option '-m64'
> 
> I think we need to properly skip tests on targets which don't support
> compile.  As far as I know, gdb compile is supported on x86, x86_64,
> and s390.

OOC, how did you determine which archs support it?  What is needed to
support compile on other Linux archs?

Isn't the aarch64 issue simply that it's missing a
gdbarch_gcc_target_options implementation to override the default
of "-m64"?

> I think we need to properly skip tests on targets which don't support
> compile.  As far as I know, gdb compile is supported on x86, x86_64,
> and s390.
> 
> This patch matches the target triplet in
> lib/gdb.exp:skip_compile_feature_tests.  If the target triplet is
> *not* x86,x86_64, and s390 linux, return 1; otherwise, do the
> "compile code -- ;" test.
> 
> An alternative approach is to modify lib/gdb.exp:skip_compile_feature_tests
> to match these error messages above.  However, these error message is
> from libcc1, subject to change, and other targets may have different
> error messages from libcc1.

A problem with white listing is the list tends to stay with the few
initial entries.  Forks working on other ports tend to not notice
the feature gated by the check exists and needs work, because they
never had to actively look at the failures and decide to blacklist
their port, or actually fix the underlying gdb issue.  Witness the
multiple cases of things like:

 # Until "catch fork" is implemented on other targets...
 #
 if { ![istarget "*-*-linux*"] && ![istarget "*-*-openbsd*"] } then {

... which is stale in the sense that other ports have grown fork
support over time, but nobody updated the tests...

So while whitelisting is the practical thing to do in many cases,
I think it doesn't hurt to raise the bar a little higher in
this case.

So "goto again;": Isn't the aarch64 issue simply that it's missing a
gdbarch_gcc_target_options implementation to override the default
of "-m64"?  What else is missing?

Thanks,
Pedro Alves

Re: [PATCH] Run gdb.compile/*.exp on {x86,x86_64,s390}-linux only

[Yao Qi]

Pedro Alves <palves@redhat.com> writes:

> OOC, how did you determine which archs support it?  What is needed to
> support compile on other Linux archs?
>

I searched the "compile" related gdbarch methods, and get the conclusion
that x86,x86_64,s390 linux are supported.  I know these gdbarch has
default implementation, so it is possible that other arch may support
compile as well, but I doubt it (I am not an optimist).

People need to implement these "compile" related gdbarch methods to
support this feature.  Also, we also need to "port" it to the distro
other than Fedora/RHEL, I've never get it working on Ubuntu.

> Isn't the aarch64 issue simply that it's missing a
> gdbarch_gcc_target_options implementation to override the default
> of "-m64"?
>

I wrote an aarch64 version of gcc_target_options to override the
option.  Note that I wrote it in 2016 Aug, with an attempt to enable
compile on aarch64-linux,

static char *
aarch64_gcc_target_options (struct gdbarch *gdbarch)
{
  return xstrdup ("");
}

and it still doesn't work (on Ubuntu),

(gdb) compile code -- ;
aarch64-none-linux-gnu-gcc: error: : No such file or directory^M
Compilation failed.

If I "set debug compile 1", I can see gcc is found, but there is still
something wrong,

searching for compiler matching regex ^aarch64(-[^-]*)?-linux(-gnu)?-gcc$^M
found compiler /home/yaoqi01/fsf-trunk-build/build-native-aarch64-none-linux-gnu/install/sysroot/usr/bin/aarch64-none-linux-gnu-gcc^M
Passing 11 compiler options:^M
Compiler option 0: <>^M
Compiler option 1: <-std=gnu11>^M
Compiler option 2: <-fno-exceptions>^M
Compiler option 3: <-O0>^M
Compiler option 4: <-gdwarf-4>^M
Compiler option 5: <-fPIE>^M
Compiler option 6: <-Wall>^M
Compiler option 7: <-Wno-implicit-function-declaration>^M
Compiler option 8: <-Wno-unused-but-set-variable>^M
Compiler option 9: <-Wno-unused-variable>^M
Compiler option 10: <-fno-stack-protector>^M
source file produced: /tmp/gdbobj-6vzbkt/out3.c^M
^M
aarch64-none-linux-gnu-gcc: error: : No such file or directory

>> I think we need to properly skip tests on targets which don't support
>> compile.  As far as I know, gdb compile is supported on x86, x86_64,
>> and s390.
>> 
>> This patch matches the target triplet in
>> lib/gdb.exp:skip_compile_feature_tests.  If the target triplet is
>> *not* x86,x86_64, and s390 linux, return 1; otherwise, do the
>> "compile code -- ;" test.
>> 
>> An alternative approach is to modify lib/gdb.exp:skip_compile_feature_tests
>> to match these error messages above.  However, these error message is
>> from libcc1, subject to change, and other targets may have different
>> error messages from libcc1.
>
> A problem with white listing is the list tends to stay with the few
> initial entries.  Forks working on other ports tend to not notice
> the feature gated by the check exists and needs work, because they
> never had to actively look at the failures and decide to blacklist
> their port, or actually fix the underlying gdb issue.  Witness the
> multiple cases of things like:
>
>  # Until "catch fork" is implemented on other targets...
>  #
>  if { ![istarget "*-*-linux*"] && ![istarget "*-*-openbsd*"] } then {
>
> ... which is stale in the sense that other ports have grown fork
> support over time, but nobody updated the tests...
>
> So while whitelisting is the practical thing to do in many cases,
> I think it doesn't hurt to raise the bar a little higher in
> this case.

I don't like the white listing either...

>
> So "goto again;": Isn't the aarch64 issue simply that it's missing a
> gdbarch_gcc_target_options implementation to override the default
> of "-m64"?  What else is missing?

See my post above.  The issue isn't as simple as "having -m64
in target options".  It is known that compile feature works on
x86/fedora, and my dest is aarch64/ubuntu.  The gap is not small.
Probably, it can be broke into two steps, x86/fedora -> x86/ubuntu ->
aarch64/ubuntu, or x86/fedora -> aarch64/fedora -> aarch64/ubuntu.

I am in a stage that triage all test fails on aarch64 and arm with
recent gcc, and I don't have an immediate plan to support compile on
aarch64-linux and arm-linux.

-- 
Yao (齐尧)

Re: [PATCH] Run gdb.compile/*.exp on {x86,x86_64,s390}-linux only

[Phil Muldoon]

On 16/01/18 15:14, Yao Qi wrote:
> Pedro Alves <palves@redhat.com> writes:
>
> People need to implement these "compile" related gdbarch methods to
> support this feature.  Also, we also need to "port" it to the distro
> other than Fedora/RHEL, I've never get it working on Ubuntu.

What were the problems? I don't work on the compile project any more
but AFAIK we made it distro neutral.

> searching for compiler matching regex ^aarch64(-[^-]*)?-linux(-gnu)?-gcc$^M
> found compiler /home/yaoqi01/fsf-trunk-build/build-native-aarch64-none-linux-gnu/install/sysroot/usr/bin/aarch64-none-linux-gnu-gcc^M
> Passing 11 compiler options:^M
> Compiler option 0: <>^M
> Compiler option 1: <-std=gnu11>^M
> Compiler option 2: <-fno-exceptions>^M
> Compiler option 3: <-O0>^M
> Compiler option 4: <-gdwarf-4>^M
> Compiler option 5: <-fPIE>^M
> Compiler option 6: <-Wall>^M
> Compiler option 7: <-Wno-implicit-function-declaration>^M
> Compiler option 8: <-Wno-unused-but-set-variable>^M
> Compiler option 9: <-Wno-unused-variable>^M
> Compiler option 10: <-fno-stack-protector>^M
> source file produced: /tmp/gdbobj-6vzbkt/out3.c^M
> ^M
> aarch64-none-linux-gnu-gcc: error: : No such file or directory

The only thing I can think of is either path or ld_library_path is not
set or not installed in those locations.

>>> I think we need to properly skip tests on targets which don't support
>>> compile.  As far as I know, gdb compile is supported on x86, x86_64,
>>> and s390.

However, I see no problem with a whitelist, even if it is disliked.

> See my post above.  The issue isn't as simple as "having -m64
> in target options".  It is known that compile feature works on
> x86/fedora, and my dest is aarch64/ubuntu.  The gap is not small.
> Probably, it can be broke into two steps, x86/fedora -> x86/ubuntu ->
> aarch64/ubuntu, or x86/fedora -> aarch64/fedora -> aarch64/ubuntu.
 
> I am in a stage that triage all test fails on aarch64 and arm with
> recent gcc, and I don't have an immediate plan to support compile on
> aarch64-linux and arm-linux.

I don't think I've ever tried it on arm. I think, if memory serves,
that Tom tried it on a Debian setup. Still, it *should* work.

Cheers

Phil

Re: [PATCH] Run gdb.compile/*.exp on {x86,x86_64,s390}-linux only

[Pedro Alves]

> searching for compiler matching regex ^aarch64(-[^-]*)?-linux(-gnu)?-gcc$^M
> found compiler /home/yaoqi01/fsf-trunk-build/build-native-aarch64-none-linux-gnu/install/sysroot/usr/bin/aarch64-none-linux-gnu-gcc^M
> Passing 11 compiler options:^M
> Compiler option 0: <>^M
> Compiler option 1: <-std=gnu11>^M
> Compiler option 2: <-fno-exceptions>^M
> Compiler option 3: <-O0>^M
> Compiler option 4: <-gdwarf-4>^M
> Compiler option 5: <-fPIE>^M
> Compiler option 6: <-Wall>^M
> Compiler option 7: <-Wno-implicit-function-declaration>^M
> Compiler option 8: <-Wno-unused-but-set-variable>^M
> Compiler option 9: <-Wno-unused-variable>^M
> Compiler option 10: <-fno-stack-protector>^M
> source file produced: /tmp/gdbobj-6vzbkt/out3.c^M
> ^M
> aarch64-none-linux-gnu-gcc: error: : No such file or directory

It sounds like the empty argument passed as "Compiler option 0" is
being interpreted by the compiler as a source file name?  And then
the error message is including the file name that is not found, 
but since the file name is the empty string, it reads a bit
cryptic.

The fix is probably to not pass that option at all if empty.

Thanks,
Pedro Alves

Re: [PATCH] Run gdb.compile/*.exp on {x86,x86_64,s390}-linux only

[Pedro Alves]

On 01/16/2018 04:59 PM, Pedro Alves wrote:
>> searching for compiler matching regex ^aarch64(-[^-]*)?-linux(-gnu)?-gcc$^M
>> found compiler /home/yaoqi01/fsf-trunk-build/build-native-aarch64-none-linux-gnu/install/sysroot/usr/bin/aarch64-none-linux-gnu-gcc^M
>> Passing 11 compiler options:^M
>> Compiler option 0: <>^M
>> Compiler option 1: <-std=gnu11>^M
>> Compiler option 2: <-fno-exceptions>^M
>> Compiler option 3: <-O0>^M
>> Compiler option 4: <-gdwarf-4>^M
>> Compiler option 5: <-fPIE>^M
>> Compiler option 6: <-Wall>^M
>> Compiler option 7: <-Wno-implicit-function-declaration>^M
>> Compiler option 8: <-Wno-unused-but-set-variable>^M
>> Compiler option 9: <-Wno-unused-variable>^M
>> Compiler option 10: <-fno-stack-protector>^M
>> source file produced: /tmp/gdbobj-6vzbkt/out3.c^M
>> ^M
>> aarch64-none-linux-gnu-gcc: error: : No such file or directory
> 
> It sounds like the empty argument passed as "Compiler option 0" is
> being interpreted by the compiler as a source file name?  And then
> the error message is including the file name that is not found, 
> but since the file name is the empty string, it reads a bit
> cryptic.
> 
> The fix is probably to not pass that option at all if empty.
> 

Yes, I could reproduce this by hacking default_gcc_target_options
to return "" like you were doing:

 Passing 15 compiler options:
 Compiler option 0: <>                 <<<<<< BAD
 Compiler option 1: <-mtune=generic>
 Compiler option 2: <-march=x86-64>
 ...

Making default_gcc_target_options return NULL instead works:

 Passing 14 compiler options:
 Compiler option 0: <-mtune=generic>
 Compiler option 1: <-march=x86-64>
 ...

Thanks,
Pedro Alves

Re: [PATCH] Run gdb.compile/*.exp on {x86,x86_64,s390}-linux only

[Yao Qi]

On Tue, Jan 16, 2018 at 5:20 PM, Pedro Alves <palves@redhat.com> wrote:
>
> Yes, I could reproduce this by hacking default_gcc_target_options
> to return "" like you were doing:
>
>  Passing 15 compiler options:
>  Compiler option 0: <>                 <<<<<< BAD
>  Compiler option 1: <-mtune=generic>
>  Compiler option 2: <-march=x86-64>
>  ...
>
> Making default_gcc_target_options return NULL instead works:
>
>  Passing 14 compiler options:
>  Compiler option 0: <-mtune=generic>
>  Compiler option 1: <-march=x86-64>
>  ...
>

Right, I can run gdb.compile/*.exp tests now on aarch64-linux,

# of expected passes            143
# of unexpected failures        10
# of known failures             2
# of untested testcases         2

-- 
Yao (齐尧)

Re: [PATCH] Run gdb.compile/*.exp on {x86,x86_64,s390}-linux only

[Sergio Durigan Junior]

On Tuesday, January 16 2018, Yao Qi wrote:

> Pedro Alves <palves@redhat.com> writes:
>
>> OOC, how did you determine which archs support it?  What is needed to
>> support compile on other Linux archs?
>>
>
> I searched the "compile" related gdbarch methods, and get the conclusion
> that x86,x86_64,s390 linux are supported.  I know these gdbarch has
> default implementation, so it is possible that other arch may support
> compile as well, but I doubt it (I am not an optimist).
>
> People need to implement these "compile" related gdbarch methods to
> support this feature.  Also, we also need to "port" it to the distro
> other than Fedora/RHEL, I've never get it working on Ubuntu.
>
>> Isn't the aarch64 issue simply that it's missing a
>> gdbarch_gcc_target_options implementation to override the default
>> of "-m64"?
>>
>
> I wrote an aarch64 version of gcc_target_options to override the
> option.  Note that I wrote it in 2016 Aug, with an attempt to enable
> compile on aarch64-linux,
>
> static char *
> aarch64_gcc_target_options (struct gdbarch *gdbarch)
> {
>   return xstrdup ("");
> }
>
> and it still doesn't work (on Ubuntu),
>
> (gdb) compile code -- ;
> aarch64-none-linux-gnu-gcc: error: : No such file or directory^M
> Compilation failed.
>
> If I "set debug compile 1", I can see gcc is found, but there is still
> something wrong,
>
> searching for compiler matching regex ^aarch64(-[^-]*)?-linux(-gnu)?-gcc$^M
> found compiler /home/yaoqi01/fsf-trunk-build/build-native-aarch64-none-linux-gnu/install/sysroot/usr/bin/aarch64-none-linux-gnu-gcc^M
> Passing 11 compiler options:^M
> Compiler option 0: <>^M
> Compiler option 1: <-std=gnu11>^M
> Compiler option 2: <-fno-exceptions>^M
> Compiler option 3: <-O0>^M
> Compiler option 4: <-gdwarf-4>^M
> Compiler option 5: <-fPIE>^M
> Compiler option 6: <-Wall>^M
> Compiler option 7: <-Wno-implicit-function-declaration>^M
> Compiler option 8: <-Wno-unused-but-set-variable>^M
> Compiler option 9: <-Wno-unused-variable>^M
> Compiler option 10: <-fno-stack-protector>^M
> source file produced: /tmp/gdbobj-6vzbkt/out3.c^M
> ^M
> aarch64-none-linux-gnu-gcc: error: : No such file or directory
>
>>> I think we need to properly skip tests on targets which don't support
>>> compile.  As far as I know, gdb compile is supported on x86, x86_64,
>>> and s390.
>>> 
>>> This patch matches the target triplet in
>>> lib/gdb.exp:skip_compile_feature_tests.  If the target triplet is
>>> *not* x86,x86_64, and s390 linux, return 1; otherwise, do the
>>> "compile code -- ;" test.
>>> 
>>> An alternative approach is to modify lib/gdb.exp:skip_compile_feature_tests
>>> to match these error messages above.  However, these error message is
>>> from libcc1, subject to change, and other targets may have different
>>> error messages from libcc1.
>>
>> A problem with white listing is the list tends to stay with the few
>> initial entries.  Forks working on other ports tend to not notice
>> the feature gated by the check exists and needs work, because they
>> never had to actively look at the failures and decide to blacklist
>> their port, or actually fix the underlying gdb issue.  Witness the
>> multiple cases of things like:
>>
>>  # Until "catch fork" is implemented on other targets...
>>  #
>>  if { ![istarget "*-*-linux*"] && ![istarget "*-*-openbsd*"] } then {
>>
>> ... which is stale in the sense that other ports have grown fork
>> support over time, but nobody updated the tests...
>>
>> So while whitelisting is the practical thing to do in many cases,
>> I think it doesn't hurt to raise the bar a little higher in
>> this case.
>
> I don't like the white listing either...
>
>>
>> So "goto again;": Isn't the aarch64 issue simply that it's missing a
>> gdbarch_gcc_target_options implementation to override the default
>> of "-m64"?  What else is missing?
>
> See my post above.  The issue isn't as simple as "having -m64
> in target options".  It is known that compile feature works on
> x86/fedora, and my dest is aarch64/ubuntu.  The gap is not small.
> Probably, it can be broke into two steps, x86/fedora -> x86/ubuntu ->
> aarch64/ubuntu, or x86/fedora -> aarch64/fedora -> aarch64/ubuntu.

Hi Yao,

It seems you found the issue, but just to let you know, there was a
related (or probably the same?) issue that I fixed a while ago on libcc1
(GCC counterpart of the "compile" plugin).  "compile" wasn't working on
Debian:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851146

And I submitted a patch to GCC to fix it:

  https://gcc.gnu.org/ml/gcc-patches/2017-08/msg01315.html

Which eventually became:

  https://gcc.gnu.org/ml/gcc-patches/2017-09/msg00087.html

This is now upstream, but if you're using Ubuntu, you may very well see
the problem with finding the right GCC compiler.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

Re: [PATCH] Run gdb.compile/*.exp on {x86,x86_64,s390}-linux only

[Yao Qi]

On Tue, Jan 16, 2018 at 6:58 PM, Sergio Durigan Junior
<sergiodj@redhat.com> wrote:
> Hi Yao,
>
> It seems you found the issue, but just to let you know, there was a
> related (or probably the same?) issue that I fixed a while ago on libcc1
> (GCC counterpart of the "compile" plugin).  "compile" wasn't working on
> Debian:
>
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851146
>
> And I submitted a patch to GCC to fix it:
>
>   https://gcc.gnu.org/ml/gcc-patches/2017-08/msg01315.html
>
> Which eventually became:
>
>   https://gcc.gnu.org/ml/gcc-patches/2017-09/msg00087.html
>
> This is now upstream, but if you're using Ubuntu, you may very well see
> the problem with finding the right GCC compiler.

Hi Sergio,
Yes, that is one issue I've seen before on Ubuntu.  I switched to
gcc trunk, then I can run gdb.compile/*.exp tests on Ubuntu.
Thanks!

There is only one fail,

bt^M
#0  _gdb_expr (__regs=0x7ffff7ff3000) at gdb command line:1^M
#1  <function called from gdb>^M
#2  main () at /home/yao.qi/SourceCode/gnu/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.compile/compile.c:106^M
(gdb) FAIL: gdb.compile/compile.exp: bt

On fedora builder, the test passes,
bt^M
#0  0x00007ffff7ff43f6 in _gdb_expr (__regs=0x7ffff7ff2000) at gdb
command line:1^M
#1  <function called from gdb>^M
#2  main () at /home/gdb-buildbot/fedora-x86-64-1/fedora-x86-64/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.compile/compile.c:106^M
(gdb) PASS: gdb.compile/compile.exp: bt

I'll fix it in test case.

-- 
Yao (齐尧)