This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 5/5] add libcc1


>>>>> "Joseph" == Joseph S Myers <joseph@codesourcery.com> writes:

>> +  self->args.push_back ("gcc");

Joseph> seems wrong - at least you should use the appropriate compiler
Joseph> name after transformation for cross compilers /
Joseph> --program-transform-name.

Ok, we'll look into it.

Joseph> I'm not clear on which library does what - does libcc1 depend in
Joseph> any way on the target or GCC version?

It doesn't depend on the target at all.  It does rely on the GCC plugin
using the same .def file -- in fact we should probably add a handshake
at the start so that we don't wind up with a version mismatch there.
The plugin is of course exposed to GCC internals changes as all plugins
are; but this is why we think it should be part of GCC.

Joseph> How are the compiler multilib options (e.g. -m32 / -m64)
Joseph> specified?  Is that something GDB passes through, based on
Joseph> examining properties of the binary being debugged?
Joseph> (Unfortunately there may not be a good way in general for GDB to
Joseph> tell what the required options for a particular binary are.  It
Joseph> can at least reasonably default to using a copy of the plugin
Joseph> for the same target triplet as GDB was configured for.)

gdb extracts some information from the debuginfo.
Some information is provided by a new gdbarch method; for example this
is where -m32 / -m64 / -m31 (hi S390) come from.

I am not sure if we can get the proper $(target_noncanonical) for a
given gdbarch.  We'll look into it.

Tom


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]