Re: [libcc1] Improve detection of triplet on compiler names

[Pedro Alves <palves at redhat dot com>]

On 08/23/2017 05:17 AM, Sergio Durigan Junior wrote:
> Hi there,
> 
> This is a series of two patches, one for GDB and one for GCC, which aims
> to improve the detection and handling of triplets present on compiler
> names.  The motivation for this series was mostly the fact that GDB's
> "compile" command is broken on Debian unstable, as can be seen here:
> 
>   <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851146>
> 
> The reason for the failure is the fact that Debian compiles GCC using
> the --program-{prefix,suffix} options from configure in order to name
> the compiler using the full triplet (i.e., Debian's GCC is not merely
> named "gcc", but e.g. "x86_64-linux-gnu-gcc-7"), which end up naming the
> C_COMPILER_NAME and CP_COMPILER_NAME defines with the specified prefix
> and suffix.  Therefore, the regexp being used to match the compiler name
> is wrong because it doesn't take into account the fact that the defines
> may already contain the triplets.

As discussed on IRC, I think the problem is that C_COMPILER_NAME
in libcc1 includes the full triplet in the first place.  I think
that it shouldn't.  I think that C_COMPILER_NAME should always
be "gcc".

The problem is in bootstrapping code, before there's a plugin
yet -- i.e.., in the code that libcc1 uses to find the compiler (which
then loads a plugin that libcc1 talks with).

Please bear with me while I lay down my rationale, so that we're
in the same page.

C_COMPILER_NAME seems to include the prefix currently in an attempt
to support cross debugging, or more generically, --enable-targets=all
in gdb, but the whole thing doesn't really work as intended if
C_COMPILER_NAME already includes a target prefix.

IIUC the libcc1/plugin design, a single "libcc1.so" (what gdb loads,
not the libcc1plugin compiler plugin) should work with any compiler in
the PATH, in case you have several in the system.  E.g., one for
each arch.

Let me expand.

The idea is that gdb always dlopens "libcc1.so", by that name exactly.
Usually that'll open the libcc1.so installed in the system, e.g.,
"/usr/lib64/libcc1.so", which for convenience was originally built from the
same source tree as the systems's compiler was built.  You could force gdb to
load some other libcc1.so, e.g., by tweaking LD_LIBRARY_PATH of course,
but you shouldn't need to.

libcc1.so is responsible for finding a compiler that targets the
architecture of the inferior that the user is debugging in gdb.
E.g., say you're cross debugging for arm-none-eabi, on a
x86-64 Fedora host.  GDB knows the target inferior's architecture, and passes
down to (the system) libcc1 a triplet regex like "arm*-*eabi*" or
similar to libcc1,.  libcc1 appends "-" + C_COMPILER_NAME to that regex,
generating something like "arm*-*eabi*-gcc", and then looks for binaries
in PATH that match that regex.  When one is found, e.g., "arm-none-eabi-gcc",
libcc1 forks/execs that compiler, passing it "-fplugin=libcc1plugin".
libcc1 then communicates with that compiler's libcc1plugin plugin
via a socket.

In this scheme, "libcc1.so", the library that gdb loads, has no
target-specific logic at all.  It should work with any compiler
in the system, for any target/arch.  All it does is marshall the gcc/gdb
interface between the gcc plugin and gdb, it is not linked against gcc.
That boundary is versioned, and ABI-stable.  So as long as the
libcc1.so that gdb loads understands the same API version of the gcc/gdb
interface API as gdb understands, it all should work.  (The APIs
are always extended keeping backward compatibility.)

So in this scheme, having the "C_COMPILER_NAME" macro in libcc1
include the target prefix for the --target that the plugin that
libcc1 is built along with, seems to serve no real purpose, AFAICT.
It's just getting in the way.

I.e., something like:

  "$gdb_specified_triplet_re" + "-" + C_COMPILER_NAME

works if C_COMPILER_NAME is exactly "gcc", but not if C_COMPILER_NAME is already:

  "$whatever_triplet_libcc1_happened_to_be_built_with" + "-gcc"

because we end up with:

  "$gdb_specified_triplet_re" + "-" "$whatever_triplet_libcc1_happened_to_be_built_with" +  "-gcc"

which is the problem case.

In sum, I think the libcc1.so (not the plugin) should _not_ have baked
in target awareness, and thus C_COMPILER_NAME should always be "gcc", and
then libcc1's regex should be adjusted to also tolerate a suffix in
the final compiler binary name regex.

WDYT?

Thanks,
Pedro Alves