On 08/23/2017 02:07 PM, Sergio Durigan Junior wrote: > On Wednesday, August 23 2017, Pedro Alves wrote: > >> On 08/23/2017 05:17 AM, Sergio Durigan Junior wrote: >>> The GCC patch improves the libcc1::compiler_triplet_regexp::find and >>> libcp1::compiler_triplet_regexp::find methods by first trying to match >>> the triplet in the compiler name and correctly discarding the triplet >>> part of the regexp if the matching succeeds. I've had to do a few >>> modifications on the way the regexp's are built, but I'll explain them >>> in the patch itself. >>> >>> The GDB patch is very simple: it adds the trailing "-" in the triplet >>> regexp. Therefore, we will have a regexp that truly matches the full >>> triplet (e.g., "^(x86_64|i.86)(-[^-]*)?-linux(-gnu)?-") instead of one >>> that leaves the trailing "-" match to libcc1. >>> >>> I've tested this patch both on my Fedora and my Debian machines, and >>> both now work as expected, independently of the presence of the triplet >>> string in the compiler name. I am sorry about the cross-post, but these >>> patches are really dependent on one another. >> >> Is there a backward/forward compatibility impact? > > Unfortunately, yes. > >> Does new GDB work with old GCC? > > No. On Fedora systems, you would get: > > Could not find a compiler matching > "^(x86_64|i.86)(-[^-]*)?-linux(-gnu)?--gcc$" >
That's a problem then. Please read this: https://sourceware.org/gdb/wiki/GCCCompileAndExecute#How_to_extend_the_gdb.2BAC8-gcc_interface > As can be seen, these failures are now happening because of the trailing > dash that is now included in the triplet regexp by GDB. I don't know if > that warrants a change in the API, though. Thanks, Pedro Alves