This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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 (齐尧)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]