Re: [PATCH 5/5] add libcc1

[Paolo Bonzini <bonzini@gnu.org>]

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