This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 5/5] add libcc1
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Paolo Bonzini <bonzini at gnu dot org>
- Cc: Phil Muldoon <pmuldoon at redhat dot com>, DJ Delorie <dj at redhat dot com>, Alexandre Oliva <aoliva at redhat dot com>, Ralf Wildenhues <Ralf dot Wildenhues at gmx dot de>, "Joseph S. Myers" <joseph at codesourcery dot com>, gcc-patches at gcc dot gnu dot org
- Date: Wed, 29 Oct 2014 11:51:32 +0100
- Subject: Re: [PATCH 5/5] add libcc1
- Authentication-results: sourceware.org; auth=none
- References: <53D9CA7B dot 3040709 at redhat dot com> <5436504B dot 8060902 at redhat dot com> <54385676 dot 4000004 at redhat dot com> <5449FC98 dot 1060404 at redhat dot com> <544A8162 dot 1090107 at redhat dot com> <544E9CE5 dot 602 at redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1410281315200 dot 3342 at digraph dot polyomino dot org dot uk> <544FD432 dot 8090004 at redhat dot com> <20141029102817 dot GP10376 at tucnak dot redhat dot com> <5450C376 dot 6000206 at gnu dot org>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
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