This is an archive of the discontinued LLVM Phabricator instance.

[ELF] - Stop handling local symbols in a special way.
ClosedPublic

Authored by grimar on Jan 23 2017, 5:45 AM.

Details

Summary

Previously we stored kept locals in a KeptLocalSyms arrays,
belonged to files.

Patch makes SymbolTableSection to store locals in Symbols member,
that already present and was used for globals.
SymbolTableSection already had NumLocals counter member, so change
itself is trivial.

That allows to simplify handling of -r,
Body::DynsymIndex is no more used as "symbol table index" for relocatable
output.

Change was suggested during review of D28773 and opens road for D28612.

Diff Detail

Repository
rL LLVM

Event Timeline

grimar created this revision.Jan 23 2017, 5:45 AM
This revision was automatically updated to reflect the committed changes.
ruiu added inline comments.Jan 23 2017, 9:49 AM
lld/trunk/ELF/SyntheticSections.cpp
1073–1077

You can use stable_partition here.

1104–1109

This is a linear scan, so this makes the algorithm O(n^2), right? Did you verify that that is not a problem? Anyway, it needs comment as always -- you should explain that this is O(n^2) but in practice it is not an issue because blah blah (if that's the case.)

grimar added inline comments.Jan 23 2017, 10:15 AM
lld/trunk/ELF/SyntheticSections.cpp
1104–1109

O(n*m). N bodies, M relocations, probably it is can be quadratic, yes.
I did not verify because it is for -relocatable only, it should be not often case.

But actually I already suggested 2 ways of solutions for that:
https://reviews.llvm.org/D28773#inline-250840

I supposed we can implement the second one just to be sure we do not have obviously slow place, what do you think ?

ruiu edited edge metadata.Jan 23 2017, 11:00 AM

Well, I think the problem was not in the code but in (the lack of) comments. It might have been OK if you add a comment saying that, for -r, we piggy back symbol's .symtab offsets to DynsymIndex because -r will never be used to produce DSOs. You probably want to spend more efforts on comments as it is sometimes the easiest way to solve a problem.

In D29021#653665, @ruiu wrote:

Well, I think the problem was not in the code but in (the lack of) comments. It might have been OK if you add a comment saying that, for -r, we piggy back symbol's .symtab offsets to DynsymIndex because -r will never be used to produce DSOs. You probably want to spend more efforts on comments as it is sometimes the easiest way to solve a problem.

I'll try.

It might have work for -relocatable, but piggybacking does not work fine for --emit-relocs (D28612) as it is possible to use it in dynamic case.
I think --emit-relocs was initial reason of why this patch appeared :)

ruiu added a comment.Jan 23 2017, 11:57 AM

Or, if you find that adding a new field to Symbol class doesn't really hurt any metrics, you can simply add it. Or, even if it slows down the linker a little bit, you may still be able to convince that that is necessary. I believe adding a new field is the simplest and sufficient way to do what you want to do, but I think you want to stop to think and investigate a few different ways, and then make your conclusion (because all I said were my guesses and not conclusions in any sense.)

In D29021#653797, @ruiu wrote:

Or, if you find that adding a new field to Symbol class doesn't really hurt any metrics, you can simply add it. Or, even if it slows down the linker a little bit, you may still be able to convince that that is necessary. I believe adding a new field is the simplest and sufficient way to do what you want to do, but I think you want to stop to think and investigate a few different ways, and then make your conclusion (because all I said were my guesses and not conclusions in any sense.)

Mmmm. Sorry, did you get this had LGTM and was already landed ? (I am not sure, I thought we discussing post commit details.)

I think I agree with Rafael that for now we can go with this solution and see if we want to optimize for -r or not separatelly later.
-relocatable output is not general use case and I think I am agree extending Symbol simply not worth doing if can be avoided.
No matter if that slows down linker or not.

This patch removed KeptLocalSyms and localized symbols handling in one place, what IMO made code cleaner. So it was useful to have.
And even if we decide to add field to Symbol, this patch helps to do that in a easy way still.