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

[Jeff Law]

On 11/15/2017 09:12 PM, Sergio Durigan Junior wrote:
> On Wednesday, November 15 2017, Jim Wilson wrote:
> 
>> On 11/13/2017 01:10 PM, Sergio Durigan Junior wrote:
>>> On Tuesday, September 26 2017, I wrote:
>>>
 Ping^2.
>>>
>>> Ping^3.
>>>
>>> I'm sending the updated ChangeLog/patch.  I'm also removing gdb-patches
>>> from the Cc list.
>>>
>>> libcc1/ChangeLog:
>>> 2017-09-01  Sergio Durigan Junior  
>>> Pedro Alves  
>>>
>>> * Makefile.am: Remove references to c-compiler-name.h and
>>> cp-compiler-name.h
>>> * Makefile.in: Regenerate.
>>> * compiler-name.hh: New file.
>>> * libcc1.cc: Don't include c-compiler-name.h.  Include
>>> compiler-name.hh.
>>> * libcp1.cc: Don't include cp-compiler-name.h.  Include
>>> compiler-name.hh.
>>
>> OK.
>>
>> This is a gcc plugin for gdb, so it makes sense that gdb developers
>> should be allowed to decide how it should work.
> 
> Thanks Jim and Alex for the review.
> 
> I don't have permission to push to the GCC repository, so if one of you
> guys could do it for me I'd appreciate.
Done.
jeff

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

[Sergio Durigan Junior]

On Wednesday, November 15 2017, Jim Wilson wrote:

> On 11/13/2017 01:10 PM, Sergio Durigan Junior wrote:
>> On Tuesday, September 26 2017, I wrote:
>>
>>> Ping^2.
>>
>> Ping^3.
>>
>> I'm sending the updated ChangeLog/patch.  I'm also removing gdb-patches
>> from the Cc list.
>>
>> libcc1/ChangeLog:
>> 2017-09-01  Sergio Durigan Junior  
>>  Pedro Alves  
>>
>>  * Makefile.am: Remove references to c-compiler-name.h and
>>  cp-compiler-name.h
>>  * Makefile.in: Regenerate.
>>  * compiler-name.hh: New file.
>>  * libcc1.cc: Don't include c-compiler-name.h.  Include
>>  compiler-name.hh.
>>  * libcp1.cc: Don't include cp-compiler-name.h.  Include
>>  compiler-name.hh.
>
> OK.
>
> This is a gcc plugin for gdb, so it makes sense that gdb developers
> should be allowed to decide how it should work.

Thanks Jim and Alex for the review.

I don't have permission to push to the GCC repository, so if one of you
guys could do it for me I'd appreciate.

Thank you,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

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

[Jim Wilson]

On 11/13/2017 01:10 PM, Sergio Durigan Junior wrote:

On Tuesday, September 26 2017, I wrote:


Ping^2.


Ping^3.

I'm sending the updated ChangeLog/patch.  I'm also removing gdb-patches
from the Cc list.

libcc1/ChangeLog:
2017-09-01  Sergio Durigan Junior  
Pedro Alves  

* Makefile.am: Remove references to c-compiler-name.h and
cp-compiler-name.h
* Makefile.in: Regenerate.
* compiler-name.hh: New file.
* libcc1.cc: Don't include c-compiler-name.h.  Include
compiler-name.hh.
* libcp1.cc: Don't include cp-compiler-name.h.  Include
compiler-name.hh.


OK.

This is a gcc plugin for gdb, so it makes sense that gdb developers 
should be allowed to decide how it should work.


Jim

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

[Alexandre Oliva]

On Nov 13, 2017, Sergio Durigan Junior  wrote:

> On Tuesday, September 26 2017, I wrote:
>> Ping^2.

> Ping^3.

> I'm sending the updated ChangeLog/patch.  I'm also removing gdb-patches
> from the Cc list.

> libcc1/ChangeLog:
> 2017-09-01  Sergio Durigan Junior  
>   Pedro Alves  

>   * Makefile.am: Remove references to c-compiler-name.h and
>   cp-compiler-name.h
>   * Makefile.in: Regenerate.
>   * compiler-name.hh: New file.
>   * libcc1.cc: Don't include c-compiler-name.h.  Include
>   compiler-name.hh.
>   * libcp1.cc: Don't include cp-compiler-name.h.  Include
>   compiler-name.hh.

I agree with Pedro's rationale.

I'm not sure I have authority to approve changes to libcc1, but since
this hasn't got a review for so long, and I'm the one who last touched
it, I kind of feel responsible and able, so I suggest that, if nobody
objects till Thursday, this is ok to install.

Thanks!

-- 
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer

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

[Sergio Durigan Junior]

On Tuesday, September 26 2017, I wrote:

> Ping^2.

Ping^3.

I'm sending the updated ChangeLog/patch.  I'm also removing gdb-patches
from the Cc list.

libcc1/ChangeLog:
2017-09-01  Sergio Durigan Junior  
Pedro Alves  

* Makefile.am: Remove references to c-compiler-name.h and
cp-compiler-name.h
* Makefile.in: Regenerate.
* compiler-name.hh: New file.
* libcc1.cc: Don't include c-compiler-name.h.  Include
compiler-name.hh.
* libcp1.cc: Don't include cp-compiler-name.h.  Include
compiler-name.hh.


> On Friday, September 15 2017, I wrote:
>
>> Ping.
>>
>> On Friday, September 01 2017, I wrote:
>>
>>> 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:
> 
>   
> 
> 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" + 

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

[Sergio Durigan Junior]

Ping^2.

On Friday, September 15 2017, I wrote:

> Ping.
>
> On Friday, September 01 2017, I wrote:
>
>> 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:
 
   
 
 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 

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

[Sergio Durigan Junior]

Ping.

On Friday, September 01 2017, I wrote:

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

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

[Sergio Durigan Junior]

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