Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Find the "best" order for local symbols #36064

Closed
llvmbot opened this issue Mar 13, 2018 · 7 comments
Closed

Find the "best" order for local symbols #36064

llvmbot opened this issue Mar 13, 2018 · 7 comments
Labels
bugzilla Issues migrated from bugzilla lld:ELF

Comments

@llvmbot
Copy link
Member

llvmbot commented Mar 13, 2018

Bugzilla Link 36716
Resolution FIXED
Resolved on Apr 11, 2018 02:25
Version unspecified
OS Linux
Reporter LLVM Bugzilla Contributor

Extended Description

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.
@llvmbot
Copy link
Member Author

llvmbot commented Mar 15, 2018

Do you have URL for discussion topic you mentioned?

@llvmbot
Copy link
Member Author

llvmbot commented Mar 16, 2018

Do you have URL for discussion topic you mentioned?

https://groups.google.com/forum/#!topic/generic-abi/tSU1wY1xyY8

@llvmbot
Copy link
Member Author

llvmbot commented Apr 2, 2018

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?

@llvmbot
Copy link
Member Author

llvmbot commented Apr 2, 2018

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?

@llvmbot
Copy link
Member Author

llvmbot commented Apr 3, 2018

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.

@llvmbot
Copy link
Member Author

llvmbot commented Apr 11, 2018

r329787

@bd1976bris
Copy link
Collaborator

mentioned in issue llvm/llvm-bugzilla-archive#48023

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 10, 2021
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bugzilla Issues migrated from bugzilla lld:ELF
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@bd1976bris @llvmbot