There is an interesting discussion at generic-abi@googlegroups.com about the order of local symbols. The ELF spec doesn't say anything about it, so we can try to figure out what is the most convenient for linkers and consumers Linking ---------------------------------- .file "file1" local1: .global hidden1 .hidden hidden1 hidden1: --------------------------------- And --------------------------------- .file "file2" local2: .global hidden2 .hidden hidden2 hidden2: -------------------------------- The results are lld: local1, local2, hidden1, hidden2 bfd: file1, corrupted file2?, hidden1, hidden2 gold: file1, local1, file2, local2, hidden1, hidden2 Gold's output has the advantage that one can map the original local symbols to a file. The exception being that the hidden symbols show up as being from file2 (one can still check the visibility to tell the difference). Two orders that might be ever better are * hidden1, hidden2, file1, local2, file2, local2 * file1, local1, hidden1, file2, local2, hidden2 The first one has the advantage of making it easy to find out the file of local symbols. The second one has the advantage of specifying where the hidden symbols came from.
Do you have URL for discussion topic you mentioned?
(In reply to George Rimar from comment #1) > Do you have URL for discussion topic you mentioned? https://groups.google.com/forum/#!topic/generic-abi/tSU1wY1xyY8
(In reply to Rafael Ávila de Espíndola from comment #0) > Two orders that might be ever better are > > * hidden1, hidden2, file1, local2, file2, local2 > * file1, local1, hidden1, file2, local2, hidden2 > > The first one has the advantage of making it easy to find out the file of > local symbols. > > The second one has the advantage of specifying where the hidden symbols came > from. The second looks nice, but LLD does not keep file symbols currently. If it makes sense to know where are locals came from, maybe it worth just to change -cref to print them out?
(In reply to George Rimar from comment #3) > (In reply to Rafael Ávila de Espíndola from comment #0) > > Two orders that might be ever better are > > > > * hidden1, hidden2, file1, local2, file2, local2 > > * file1, local1, hidden1, file2, local2, hidden2 > > > > The first one has the advantage of making it easy to find out the file of > > local symbols. > > > > The second one has the advantage of specifying where the hidden symbols came > > from. > > The second looks nice, but LLD does not keep file symbols currently. > If it makes sense to know where are locals came from, maybe it worth just to > change -cref to print them out? The tool we have uses just .o files, so we would have to write it there. Adding file symbols to lld should be simple, no?
(In reply to Rafael Ávila de Espíndola from comment #4) > (In reply to George Rimar from comment #3) > > (In reply to Rafael Ávila de Espíndola from comment #0) > > > Two orders that might be ever better are > > > > > > * hidden1, hidden2, file1, local2, file2, local2 > > > * file1, local1, hidden1, file2, local2, hidden2 > > > > > > The first one has the advantage of making it easy to find out the file of > > > local symbols. > > > > > > The second one has the advantage of specifying where the hidden symbols came > > > from. > > > > The second looks nice, but LLD does not keep file symbols currently. > > If it makes sense to know where are locals came from, maybe it worth just to > > change -cref to print them out? > > The tool we have uses just .o files, so we would have to write it there. > Adding file symbols to lld should be simple, no? Should be. That will increase the output size by some amount. I can do a patch to enable file symbols and check the clang binary difference, for start.
r329787