On Wed, Oct 29, 2014 at 11:37:42AM +0100, Paolo Bonzini wrote: > > > On 10/29/2014 11:28 AM, Jakub Jelinek wrote: > > If this passes bootstrap/regtest, is it ok for trunk (should fix > > two bootstrap issues)? Is the > > https://gcc.gnu.org/ml/gcc-patches/2014-10/msg02936.html > > patch ok too (that one already tested; another bootstrap issue)? > > Both seem okay, though I'd have to look at the whole thread to > understand what libcc1 is. :)
It is a library for communication between the debugger and a GCC plugin (and the plugin itself). So, the library is dlopened into GDB and the plugin that links against that library is dlopened by GCC when GDB asks the library it dlopened to run the compiler with the plugin. > Just two questions: > > 1) what's the issue that you need to disable asan for? -fsanitize=address generally doesn't work or doesn't work too well, if the binary is not built with -fsanitize=address, but shared library dlopened into it is. So, we want to avoid instrumenting plugins that way (we already don't instrument lto-plugin for that reason, because ld might not be asan instrumented, and libcc1 is similar case, when gdb dlopens the library, it might not be instrumented either). > 2) why is GMPLIB not handled in the same way? The only problem is that system.h includes gmp.h, so we need a way to find that header. I think libcc1 doesn't use any functions from gmp itself, so if gmp.h can be included, GMPLIB isn't really needed. Jakub