Message ID | 1516103412-25086-1-git-send-email-yao.qi@linaro.org |
---|---|
State | New, archived |
Headers |
Received: (qmail 57868 invoked by alias); 16 Jan 2018 11:50:29 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 57856 invoked by uid 89); 16 Jan 2018 11:50:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00, FREEMAIL_FROM, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-spam-relays-external:209.85.128.194, H*RU:209.85.128.194, H*r:sk:static. X-HELO: mail-wr0-f194.google.com Received: from mail-wr0-f194.google.com (HELO mail-wr0-f194.google.com) (209.85.128.194) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 16 Jan 2018 11:50:18 +0000 Received: by mail-wr0-f194.google.com with SMTP id z48so14863097wrz.6 for <gdb-patches@sourceware.org>; Tue, 16 Jan 2018 03:50:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=0MquY8jo/4zyUhoZYD2XLZlb2WlZBkGy65xXSCIpl8c=; b=ig0BopmtCbovY9yxHE1IApW3nkHo1HNHapEkvRSZbXVh/JutchGNZdJ+ETvRPcGcHe U6gRzz8xw6+A7USk1J8ayGXxYEStizOYiNB7CcYj9wDSWTrsjJM2eHQcbI/F6zkUXyjy G0wkdmtZM47oQ+K1R/h84Xq6HcIp4Z/m8qYW6sAXadRjAvGEybOXNyFpoe19qnqANIFQ GloMIEEY65bSReonhBjZWs11IU9SpWrfzU5VR7Pdj2TnLrxa7OOctjrrU2GlL7jBzkxt eselVw5SKU61/ku9b/zl98pIrqOG+lgacG+8+ZJ3inU3JUXzonGsFPurqnTxHKbs25XT kO8g== X-Gm-Message-State: AKwxytfaCKX13WrQmXl0QxqPjiaZOzfrdvUG9k2UHH5W/yjxp72NCIkY LVflUjO6H5/bb3r1BaNrbfgOjQ== X-Google-Smtp-Source: ACJfBovX/fKpvFIGso+7i5Bgu50jEsAKAYwtiZIhuHj4VmhsTW48OkUH2+T8C0wv64b1MeczK55/gg== X-Received: by 10.223.179.193 with SMTP id x1mr4785581wrd.171.1516103416563; Tue, 16 Jan 2018 03:50:16 -0800 (PST) Received: from E107787-LIN.cambridge.arm.com (static.42.136.251.148.clients.your-server.de. [148.251.136.42]) by smtp.gmail.com with ESMTPSA id i1sm5441183wrh.96.2018.01.16.03.50.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 16 Jan 2018 03:50:16 -0800 (PST) From: Yao Qi <qiyaoltc@gmail.com> X-Google-Original-From: Yao Qi <yao.qi@linaro.org> To: gdb-patches@sourceware.org Cc: jan.kratochvil@redhat.com, pmuldoon@redhat.com Subject: [PATCH] Run gdb.compile/*.exp on {x86,x86_64,s390}-linux only Date: Tue, 16 Jan 2018 11:50:12 +0000 Message-Id: <1516103412-25086-1-git-send-email-yao.qi@linaro.org> X-IsSubscribed: yes |
Commit Message
Yao Qi
Jan. 16, 2018, 11:50 a.m. UTC
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(-)
Comments
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
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.
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
> 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
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
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
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,
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.
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 }