On Fri, 16 May 2014, Tom Tromey wrote:
> This patch adds the plugin to the gcc tree and updates the top-level
> configury.
I don't see anything obvious that would disable the plugin if plugins are
unsupported (e.g. on Windows host) or disabled (--disable-plugin).
Probably the relevant support from gcc/configure.ac needs to go somewhere
it can be used at toplevel.
> + self->args.push_back ("gcc");
seems wrong - at least you should use the appropriate compiler name after
transformation for cross compilers / --program-transform-name. Though
really the *versioned* driver $(target_noncanonical)-gcc-$(version) is the
right one to use, in that the plugin should presumably be closely
associated with a particular compiler installation when e.g. a
distribution has multiple GCC versions packaged that can be installed
simultaneously. Having multiple copies of the plugin installed in the
same prefix for different targets should be supported. I'm not clear on
which library does what - does libcc1 depend in any way on the target or
GCC version?
How are the compiler multilib options (e.g. -m32 / -m64) specified? Is
that something GDB passes through, based on examining properties of the
binary being debugged? (Unfortunately there may not be a good way in
general for GDB to tell what the required options for a particular binary
are. It can at least reasonably default to using a copy of the plugin for
the same target triplet as GDB was configured for.)
--
Joseph S. Myers
jos...@codesourcery.com
