This is an archive of the discontinued LLVM Phabricator instance.

IR: Introduce can_omit_from_dynsym attribute.
AbandonedPublic

Authored by pcc on May 13 2016, 2:13 PM.

Details

Reviewers
rafael
Summary

If this attribute is given and all modules in the linkage unit have this
attribute, this value may be omitted from the dynamic symbol table. This
is set on constant linkonce_odr globals whose addresses are insignificant
within the module. Because such globals must be defined in each linkage unit
that uses them, a valid program would not be able to observe the absence of
the symbol unless its address is significant.

Part of the fix for PR27553.

Diff Detail

Event Timeline

pcc updated this revision to Diff 57251.May 13 2016, 2:13 PM
pcc retitled this revision from to IR: Introduce can_omit_from_dynsym attribute..
pcc updated this object.
pcc added a reviewer: rafael.
pcc added a subscriber: llvm-commits.

Great, I had in my todo list to look how to move this out of the the object emission to the IR level.
Any reason for the name change though? The one you came up with does not sound pretty to me, what was wrong with weak_def_can_be_hidden or xxxx_can_be_hidden?

pcc added a comment.May 13 2016, 2:37 PM

It's basically the same name as the function it replaces, canBeOmittedFromSymbolTable with a tweak for accuracy. That said I don't feel strongly about the name.

rafael edited edge metadata.May 13 2016, 2:39 PM
rafael added a subscriber: rafael.

As for naming, I would probably name it after what it checks, not what
it is currently used for.

How about making the attribute be just "address_not_used_in_module"?
The other properties (like being linkonce_odr) are easy to check
without having to walk all uses.

Should the verifier check if this the property is invalidly set?

Cheers,
Rafael

As for naming, I would probably name it after what it checks, not what
it is currently used for.

How about making the attribute be just "address_not_used_in_module"?
The other properties (like being linkonce_odr) are easy to check
without having to walk all uses.

Should the verifier check if this the property is invalidly set?

Cheers,
Rafael

How about unnamed_addr_in_module?

pcc added a comment.May 13 2016, 2:52 PM

I tried going that way to begin with (D20260) but after I was done it felt a little too complicated to me, so I redid it with just what we needed. If others disagree maybe we can go with that patch instead of this one.

pcc abandoned this revision.May 16 2016, 9:27 AM

Okay, let's go with D20260 then.

Should the verifier check if this the property is invalidly set?

Sounds like a good idea to me, I'll do that on the other patch.