Design/implementation alternatives for the driver and WPA

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

Sure. It seems to me that the pass 1, middle, pass 2 breakdown is
pretty common for linkers, though perhaps not universal. I'll find a
better name (I wasn't really happy with this name anyway.)

* The linker does normally copy unrecognized sections with the
SHF_ALLC 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.

K, as Daniel suggested, we could have the compiler set the
SHF_EXCLUDE bit as well for those sections, and add support for that
in gold (if it's not already there).

* 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 STTBJECT, the
common symbol becomes an undefined reference to the shared library.
For STT_FUNCTIN, it does not. Gold does not currently behave this
way common symbol always overrides. But in any case, there is
some precedent for worrying about symbol type.

I don't think so, but I'll take a closer look. I think we don't really
need to worry about the type of the symbol until we get the real .o
file.

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

K.

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

, forgot about that.

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

K. What would be reasonable to say here? Just a string of the form
"n.m"? Is it reasonable to require that later versions are lexically
greater than earlier versions (e.g., can't have "1.9" then "1.10"), or
is it K to require parsing the string to do comparisons?

* 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. it might
be reasonable to just take a string, and push formatting to the
plugin.

Yeah, I almost put "" there instead. Probably better than va_list.

-cary