[v2,libcc1] Rename C{,P}_COMPILER_NAME and remove triplet from them

  On Wednesday, August 23 2017, Pedro Alves wrote:

> 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?

As I replied before, I agree with Pedro's rationale here and his idea
actually makes my initial patch much simpler.  By renaming
C_COMPILER_NAME (and the new CP_COMPILER_NAME) to just "gcc" (or "g++"),
the Debian bug I was fixing is solved and we don't have to bother with
breaking compatibility with older gdb's packaged by the distros, because
they will also keep working with this change.

So I would like to propose this new patch, only for GCC, which makes
C_COMPILER_NAME and CP_COMPILER_NAME have "gcc" and "g++" as hardcoded
names, respectively.  In the commit log, I intend to include Pedro's
rationale (above).

What do you guys think of this new version?  It doesn't need any GDB
patch, and works with both Fedora and Debian.

Thanks,

[v2,libcc1] Rename C{,P}_COMPILER_NAME and remove triplet from them

Commit Message

Comments

Patch