I'm building a C++ shared library project. When I add "--coverage" to CXXFLAGS,
the project fails to compile because libtool uses --nostdlib. The error message
is not that helpful:
.libs/variable_printer: hidden symbol `atexit' in
/usr/lib64/libc_nonshared.a(atexit.oS) is referenced by DSO
final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status
make: *** [variable_printer] Error 1
The message doesn't tell where the hidden symbol is referenced from. I need to
run readelf to figure what's going on. I wonder if the error output could be
improved to show the information.
I worked on one solution for this issue last month. The method I used was to just make a list of external symbols for each input object (just a linked list that points to the symbol entries in the hash table). Then, when the error is detected and it is time to emit a message, I just went through the list of input objects and scanned each list of external symbols, looking for the symbol entry that matches the entry for the hidden symbol. They are one and the same. Once I find a matching symbol, I know which object file contained the reference to the hidden symbol and could just print the name of that DSO.
As noted, there is a small amount of overhead during the processing of input files, to create the lists, but the overhead is a 4-byte pointer to the list and then 8 bytes for each external symbol. As an alternative, since this message doesn't occur too often, a linker option could be added and the original error message modified so the user just has to do one extra link to identify the name of the DSO.
There are other methodsfor solving this problem, such as reopening all input objects and checking them for an external symbol matching the hidden symbol. I just choose a solution that did not require a lot of changes to the BFD library.
My patch hasn't been reviewed yet, so it is not yet merged into the latest Binutils trunk.
Have you submitted your patch for review ? I do not remember seeing it on the mailing lists.
The idea sounds good though. One possible enhancement is to disable the feature if the user has specified --reduce-memory-overheads on the linker command line.
If you would care to submit a small, self-contained test case that could be fitted into the linker testsuite that would be a great help as well.
No, Nick, I haven't submitted any kind of patch or such as yet. I was waiting on an internal company review first, before sending the fix upstream. Your comment about tying the reduced-memory option into whether the symbols are stored sounds reasonable. Odds are that it will become part of the patch.