c_diagnostic_ignored_function hack

In the typical case, when compiling a snippet of user code, gdb wraps
the user's text in a dummy function.

It's somewhat odd for users if an error in their code is mentioned as
coming from this dummy function.

This patch makes it possible to suppress the function-name display in
a straightforward way: it adds a new global which the plugin can set
to declare the name of the dummy function.

This patch seems like a bit of a hack, but there didn't seem to be a
notably cleaner approach.

2014-05-12  Phil Muldoon  <pmuldoon@redhat.com>
	    Jan Kratochvil  <jan.kratochvil@redhat.com>
	    Tom Tromey  <tromey@redhat.com>

	* c-lang.c (c_diagnostic_ignored_function): New global.
	(c_print_error_function): New function.
	(LANG_HOOKS_PRINT_ERROR_FUNCTION): Define.
	* c-lang.h (c_diagnostic_ignored_function): Declare.
introduce the binding oracle

gdb wants to supply any declarations that may be referred to by the
user's code.  Hooking into symbol lookup was an efficient way to
accomplish this.

This patch introducing a "binding oracle" that is consulted whenever a
symbol binding is looked up for the first time.  The oracle is just a
global function pointer.  If it is NULL, no special work is done.  It
is called with the identifier to supply and with an enum argument
indicating the kind of binding being requested.  The oracle can then
call back into the C front end (via the new functions c_pushtag and
c_bind) to supply a binding; or it can silently do nothing if the
request could not be fulfilled.

The code caches Whether the oracle has been called to avoid repeated
useless queries.

There is a little hack in c_print_identifier to avoid calling the
binding oracle here.  This makes debugging gcc in the presence of the
plugin remain relatively sane -- without this, calling debug_tree or
the like can confusingly call into the plugin.

2014-05-12  Phil Muldoon  <pmuldoon@redhat.com>
	    Jan Kratochvil  <jan.kratochvil@redhat.com>
	    Tom Tromey  <tromey@redhat.com>

	* c-tree.h (enum c_oracle_request): New.
	(c_binding_oracle_function): New typedef.
	(c_binding_oracle, c_pushtag, c_bind): Declare.
	* c-decl.c (c_binding_oracle): New global.
	(I_SYMBOL_CHECKED): New macro.
	(i_symbol_binding): New function.
	(I_SYMBOL_BINDING, I_SYMBOL_DECL): Redefine.
	(I_TAG_CHECKED): New macro.
	(i_tag_binding): New function.
	(I_TAG_BINDING, I_TAG_DECL): Redefine.
	(I_LABEL_CHECKED): New macro.
	(i_label_binding): New function.
	(I_LABEL_BINDING, I_LABEL_DECL): Redefine.
	(c_print_identifier): Save and restore c_binding_oracle.
	(c_pushtag, c_bind): New functions.
add gcc/gdb interface files

The gcc plugin is split into two parts.  One part is an ordinary gcc
plugin.  The other part is a shared library that is loaded by gdb.

This patch adds some files that define the interface exported by this
shared library to gdb.  These files also define the internal API by
which the gdb- and gcc-sides communicate.

These files will be kept in sync between gcc and gdb like much of
include/.

The exported API has been intentionally kept very simple.  In
particular only a single function is exported from the gdb-side
library; symbol visibility is used to hide everything else.  This
exported symbol is a function which is called to return a structure
holding function pointers that gdb then uses.  This structure is
versioned so that changes can be made without necessarily requiring a
simultaneous gdb upgrade.

Note that the C compiler API is broken out separately.  This lets us
extend it to other GCC front ends as desired.  We plan to investigate
C++ in the future.

2014-05-12  Phil Muldoon  <pmuldoon@redhat.com>
	    Jan Kratochvil  <jan.kratochvil@redhat.com>
	    Tom Tromey  <tromey@redhat.com>

	* gcc-c-fe.def: New file.
	* gcc-c-interface.h: New file.
	* gcc-interface.h: New file.
add libcc1

This patch adds the plugin to the gcc tree and updates the top-level
configury.

It seems better to have this code in the gcc tree than in the gdb
tree, because it is bound more tightly to gcc.  The gcc plugin makes
direct calls into various parts of gcc to do its work; whereas on the
gdb side everything is done via a relatively simple API, without any
direct connection to gdb internals.  This breakdown made the most
sense because most calls are from gdb to gcc rather than vice versa.

The plugin itself consists of two parts.  These parts communicate via
a simple ad hoc RPC system implemented in the plugin code.

2014-05-12  Phil Muldoon  <pmuldoon@redhat.com>
	    Jan Kratochvil  <jan.kratochvil@redhat.com>
	    Tom Tromey  <tromey@redhat.com>

	* Makefile.def: Add libcc1 to host_modules.
	* configure.ac (host_tools): Add libcc1.
	* Makefile.in, configure: Rebuild.

2014-05-12  Phil Muldoon  <pmuldoon@redhat.com>
	    Jan Kratochvil  <jan.kratochvil@redhat.com>
	    Tom Tromey  <tromey@redhat.com>

	* aclocal.m4: New file.
	* callbacks.cc: New file.
	* callbacks.hh: New file.
	* cc1plugin-config.h.in: New file.
	* configure: New file.
	* configure.ac: New file.
	* connection.cc: New file.
	* connection.hh: New file.
	* libcc1.cc: New file.
	* libcc1plugin.sym: New file.
	* libcc1.sym: New file.
	* Makefile.am: New file.
	* Makefile.in: New file.
	* marshall.cc: New file.
	* marshall.hh: New file.
	* names.cc: New file.
	* names.hh: New file.
	* plugin.cc: New file.
	* rpc.hh: New file.
	* status.hh: New file.