This is an archive of the discontinued LLVM Phabricator instance.

MC: For variable symbols, maintain MCSymbol::Section as a cache.
ClosedPublic

Authored by pcc on Mar 24 2015, 11:59 AM.

Details

Summary

This fixes the visibility of symbols in certain edge cases involving aliases
with multiple levels of indirection.

Diff Detail

Repository
rL LLVM

Event Timeline

pcc updated this revision to Diff 22590.Mar 24 2015, 11:59 AM
pcc retitled this revision from to MC: For variable symbols, maintain MCSymbol::Section as a cache..
pcc updated this object.
pcc edited the test plan for this revision. (Show Details)
pcc added a reviewer: rafael.
pcc added a subscriber: Unknown Object (MLST).
rafael edited edge metadata.Mar 24 2015, 1:17 PM

This is a step in the right direction to fix https://llvm.org/bugs/show_bug.cgi?id=19582

Thanks for working on this!

include/llvm/MC/MCSymbol.h
73 ↗(On Diff #22590)

Why not just getSection?

lib/MC/MCExpr.cpp
787 ↗(On Diff #22590)

This is not always correct, but I guess it is less wrong than the case that follows.

lib/Target/AArch64/MCTargetDesc/AArch64AsmBackend.cpp
520 ↗(On Diff #22590)

This can just use EvaluateAsRelocatable and can be an independent fix.

test/MC/ELF/alias.s
111 ↗(On Diff #22590)

Can these CHECK-NOT go in first as an independent cleanup?

pcc updated this revision to Diff 22602.Mar 24 2015, 2:53 PM
pcc edited edge metadata.

Separate out cleanups

include/llvm/MC/MCSymbol.h
73 ↗(On Diff #22590)

This class already has a getSection function. Or are you suggesting that we should also be updating the callers to expect a pointer from this function? That seems like it should be a separate change if anything.

lib/MC/MCExpr.cpp
787 ↗(On Diff #22590)

Right, we probably can't do much better here without more context.

lib/Target/AArch64/MCTargetDesc/AArch64AsmBackend.cpp
520 ↗(On Diff #22590)

r233119

test/MC/ELF/alias.s
111 ↗(On Diff #22590)

r233118

pcc updated this revision to Diff 22605.Mar 24 2015, 3:03 PM
  • Add test from PR19582
rafael accepted this revision.Mar 24 2015, 3:32 PM
rafael added a reviewer: grosbach.
rafael edited edge metadata.

I am pretty certain this is going the right way.

Just give grosbach a chance to look a the MachO changes.

This revision is now accepted and ready to land.Mar 24 2015, 3:33 PM
grosbach edited edge metadata.Mar 24 2015, 3:43 PM

There's not enough information in the description for me to go on. Which edge cases? How/why were they wrong before?

For example, the fact that this patch changes the results in the MachO test concerns me. Why are the old values incorrect and the new ones correct? The first two changes look like it's a difference in order of what's in the object file, which is probably fine, but alias_to_local refers to __data now where before it did not. Why?

pcc added a comment.Mar 24 2015, 4:46 PM

There's not enough information in the description for me to go on. Which edge cases? How/why were they wrong before?

test/MC/ELF/alias.s shows one specific test case that was problematic before. The problem was that .Llocal1 was given external linkage despite being a local symbol. The new code correctly does not create a symbol for .Llocal1.

For example, the fact that this patch changes the results in the MachO test concerns me. Why are the old values incorrect and the new ones correct? The first two changes look like it's a difference in order of what's in the object file, which is probably fine, but alias_to_local refers to __data now where before it did not. Why?

The previous output showed that alias_to_local was given a section of 0, which was incorrect because a section value of 0 indicates that the symbol is defined externally. The new code correctly resolves the section to __data which is where alias_to_local's referent .Ltmp0 is defined.

For example, the fact that this patch changes the results in the MachO test concerns me. Why are the old values incorrect and the new ones correct? The first two changes look like it's a difference in order of what's in the object file, which is probably fine, but alias_to_local refers to __data now where before it did not. Why?

The previous output showed that alias_to_local was given a section of 0, which was incorrect because a section value of 0 indicates that the symbol is defined externally. The new code correctly resolves the section to __data which is where alias_to_local's referent .Ltmp0 is defined.

Tim, you added this test with r209894 to support N_INDR. My
understanding is that this is the case of "N_INDR can't represent
this, produce *something*". Is that so?

Cheers,
Rafael

t.p.northover edited edge metadata.Mar 30 2015, 1:26 PM

I'm afraid I've forgotten most of these details. I can't *see* anything wrong with the MachO changes though; still seems like a reasonable representation of the situation.

This revision was automatically updated to reflect the committed changes.