Re: [whopr] Design/implementation alternatives for the drive…

Top Page

Reply to this message
Author: Ian Lance Taylor
Date:  
To: Cary Coutant
CC: Diego Novillo, gcc, Kenneth Zadeck, Jan Hubicka, Rafael Espindola, Ollie Wild, Robert Hundt
Subject: Re: [whopr] Design/implementation alternatives for the driver and WPA
"Cary Coutant" <ccoutant@???> writes:

>> We've started working on the driver and WPA components for whopr.
>> These are some of our initial thoughts and implementation strategy. I
>> have linked these to the WHOPR page as well. I'm hoping we can
>> discuss these at the Summit BoF, so I'm posting them now to start the
>> discussion.
>
> I've updated the WHOPR Driver wiki page with our latest thoughts on
> the plug-in interface:
>
> http://gcc.gnu.org/wiki/whopr/driver


A few comments.

* "End of first pass" may be a little gold specific. Perhaps it
should be called something like "after all input files have been
seen."

* The linker does normally copy unrecognized sections with the
SHF_ALLOC bit clear to the output file. It doesn't allocate address
space for them, but it does copy them. I think this follows the ELF
ABI. I don't know of any generic way to direct the linker to not
copy sections to the output file.

* Do we need to worry about the type of the symbol in the "add
symbols" interface? For example, what about a TLS symbol? Also,
when the GNU linker sees a common symbol in a regular object and a
symbol with the same name in a shared library, the action depends on
the type of the symbol in the shared library. For STT_OBJECT, the
common symbol becomes an undefined reference to the shared library.
For STT_FUNCTION, it does not. Gold does not currently behave this
way--the common symbol always overrides. But in any case, there is
some precedent for worrying about symbol type.

* The command line arguments should explicitly be placed in the
transfer vector in the order in which they appear on the command
line.

* Type names ending in "_t" are reserved by POSIX. We shouldn't use
them (I'm looking at ld_plugin_status_t).

* GOLD_VERSION should perhaps say something about the format of the
string.

* I guess that having the message hook take a va_list is most
flexible, but it is inconvenient for typical uses. Taking a
variable number of arguments would be more convenient. Or it might
be reasonable to just take a string, and push formatting to the
plugin.

Ian