On 10/29/2014 11:51 AM, Jakub Jelinek wrote: > 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).
Thanks for explaining. I can see intuitively why that could be a problem... >> 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. Ah, got it. Is it hard to move the inclusion to the actual users? Paolo
