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

[Sergio Durigan Junior <sergiodj at redhat dot com>]

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/