From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 129065 invoked by alias); 16 Jan 2018 18:58:51 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 129046 invoked by uid 89); 16 Jan 2018 18:58:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,KAM_SHORT,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=became X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 16 Jan 2018 18:58:48 +0000 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9FEA34A6F3; Tue, 16 Jan 2018 18:58:47 +0000 (UTC) Received: from localhost (unused-10-15-17-193.yyz.redhat.com [10.15.17.193]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4881460C97; Tue, 16 Jan 2018 18:58:43 +0000 (UTC) From: Sergio Durigan Junior To: Yao Qi Cc: Pedro Alves , gdb-patches@sourceware.org, jan.kratochvil@redhat.com, pmuldoon@redhat.com Subject: Re: [PATCH] Run gdb.compile/*.exp on {x86,x86_64,s390}-linux only References: <1516103412-25086-1-git-send-email-yao.qi@linaro.org> <088c44b5-5454-e187-3984-956a30904ffc@redhat.com> <86k1whg7iy.fsf@gmail.com> Date: Tue, 16 Jan 2018 18:58:00 -0000 In-Reply-To: <86k1whg7iy.fsf@gmail.com> (Yao Qi's message of "Tue, 16 Jan 2018 15:14:45 +0000") Message-ID: <87tvvlzl3x.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2018-01/txt/msg00317.txt.bz2 On Tuesday, January 16 2018, Yao Qi wrote: > Pedro Alves 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/