From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 104256 invoked by alias); 16 Jan 2018 15:14:54 -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 104246 invoked by uid 89); 16 Jan 2018 15:14:53 -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,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-spam-relays-external:74.125.82.66, H*RU:74.125.82.66 X-HELO: mail-wm0-f66.google.com Received: from mail-wm0-f66.google.com (HELO mail-wm0-f66.google.com) (74.125.82.66) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 16 Jan 2018 15:14:52 +0000 Received: by mail-wm0-f66.google.com with SMTP id 141so9282481wme.3 for ; Tue, 16 Jan 2018 07:14:51 -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:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=BylcdlPAZrrifZuYLkOZK4RNKGUzRK6eSVVdOofbAY8=; b=DgFfFXblXMNlh+FIe+M9KvUr/uuv+ZMhQq7ayk/B9Ziz5FuSMcbNge9+CcfFNcRoj6 nz7MJWx1ith7kyr7mh5aXp3xzG3T3jcCM0kUGXmtTdAR2XF2OzqgZ8w6FiV6Psee6UqX sF1y86YeVOZf+gaQEQp9eAfjbkUpdHwJG37zs3O7mMqEOY48Lf0y1fQxhltFND3RStZc UZev2JVJiFw3S6wWD/XIL9IIVYnSta4esElEmmDUUIBpwajImgrA2a0e7mjFbMnATfBr alUPP7GLhylMCgT2tfYQEZ9s5QXaJdezTbG976oz9EQaXU4abjbLdTSAiIch4Ht+DOiR EZrA== X-Gm-Message-State: AKwxytdJXvmuWLosjCz2TcfREFt4AHc5ywyrrI2pCASWDwnHQ3g4aO+a jaAQ8l4Q6VJ63q3IBL55ND0= X-Google-Smtp-Source: ACJfBosvfvojGLs9HqYe/QGOGmsamUS9lFo5Jl04Dpgslq2xXK2eHedPFeWsK5LPWI9mjfsMjyjj+A== X-Received: by 10.28.198.12 with SMTP id w12mr13323195wmf.75.1516115689803; Tue, 16 Jan 2018 07:14:49 -0800 (PST) Received: from E107787-LIN (static.42.136.251.148.clients.your-server.de. [148.251.136.42]) by smtp.gmail.com with ESMTPSA id y134sm3045252wme.12.2018.01.16.07.14.48 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Tue, 16 Jan 2018 07:14:49 -0800 (PST) From: Yao Qi To: Pedro Alves Cc: 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> Date: Tue, 16 Jan 2018 15:14:00 -0000 In-Reply-To: <088c44b5-5454-e187-3984-956a30904ffc@redhat.com> (Pedro Alves's message of "Tue, 16 Jan 2018 12:18:43 +0000") Message-ID: <86k1whg7iy.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2018-01/txt/msg00298.txt.bz2 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-linu= x-gnu/install/sysroot/usr/bin/aarch64-none-linux-gnu-gcc^M Passing 11 compiler options:^M Compiler option 0: <>^M Compiler option 1: <-std=3Dgnu11>^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. >>=20 >> 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. >>=20 >> An alternative approach is to modify lib/gdb.exp:skip_compile_feature_te= sts >> 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. --=20 Yao (=E9=BD=90=E5=B0=A7)