> * "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_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. OK, 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 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. 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. OK. > * Type names ending in "_t" are reserved by POSIX. We shouldn't use > them (I'm looking at ld_plugin_status_t). Oops, forgot about that. > * GOLD_VERSION should perhaps say something about the format of the > string. OK. 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 OK 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. Or 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
