Re: [whopr] Design/implementation alternatives for the driver and WPA

[Ian Lance Taylor <iant at google dot com>]

"Cary Coutant" <ccoutant@google.com> 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