This is an archive of the discontinued LLVM Phabricator instance.

[llvm-nm] Fix handling of symbol types 't' 'd' 'r'
ClosedPublic

Authored by MaskRay on May 4 2019, 3:17 AM.

Details

Summary

This restores part of r359311 that was reverted by r359830.

Rewrite the symbol types to fix several issues.

Notable difference is that the type of __init_array_start changes from
't' to 'd'.

GNU nm used to mark ELF symbols relative to .init_array as 't'
https://sourceware.org/bugzilla/show_bug.cgi?id=24505 (before 2.33)
because ".init" is the prefix. The bug was copied by r287803.

Diff Detail

Repository
rL LLVM

Event Timeline

MaskRay created this revision.May 4 2019, 3:17 AM

Since you're using yaml2obj, can these tests be pulled up out of the X86 directory, into the top-level llvm-nm test directory? That would allow for testing even if X86 is unsupported.

test/tools/llvm-nm/X86/bss.test
9–12 ↗(On Diff #198133)

Nit: not that it really matters, but you could reduce the amount of padding here a bit. Similar comments apply to the other tests.

test/tools/llvm-nm/X86/data.test
1 ↗(On Diff #198133)

This test seems needlessly complicated for what it's testing (I think). I think it would also be nice to name the symbols and sections according to what is actually important for this test case (i.e. it's not the name ".data" that is important, it's the section flags/type etc).

How about splitting off the read-only (r/R) symbols into a different test case?

38–39 ↗(On Diff #198133)

Do you really need this symbol and the .eh_frame section for this test? What is it showing different to the regular data symbols?

42–45 ↗(On Diff #198133)

These symbols should be STT_TLS or not exist at all, as otherwise they aren't showing us anything interesting.

test/tools/llvm-nm/X86/linker-synthesized.test
1 ↗(On Diff #198133)

What is this test actually testing that is not tested by other tests?

test/tools/llvm-nm/X86/nonalloc.test
3 ↗(On Diff #198133)

Nit: new line before the yaml blob for readability.

MaskRay updated this revision to Diff 198451.May 7 2019, 5:51 AM
MaskRay marked 9 inline comments as done.

Address review comments

MaskRay added inline comments.May 7 2019, 5:51 AM
test/tools/llvm-nm/X86/data.test
1 ↗(On Diff #198133)

Created readonly.test

38–39 ↗(On Diff #198133)

Deleted .eh_frame

42–45 ↗(On Diff #198133)

These symbols have no types. Only their sections matter.

test/tools/llvm-nm/X86/linker-synthesized.test
1 ↗(On Diff #198133)

This can be seen as a generalized init_fini.test. It is to prevent D26937. I can delete it if you think it not useful.

jhenderson requested changes to this revision.May 8 2019, 2:59 AM

Requesting changes due to the difference versus GNU.

test/tools/llvm-nm/bss.test
1 ↗(On Diff #198451)

This test should probably be renamed to nobits.test, since that's what is important. It might also be worth showing the behaviour with and without SHF_ALLOC and SHF_EXECINSTR, to show that the section type has precedence here.

test/tools/llvm-nm/data.test
1 ↗(On Diff #198451)

I'd still like the names of symbols and sections in this test to be more clearly arbitrary, since the code doesn't care what the names are (but a naive user might think that it does). For example, perhaps you could name your sections simply .foo, .bar, etc or .nobits_tls_alloc_write or something, depending on whether you think the name should reflect the flags or not.

The same goes for names in the other tests.

20 ↗(On Diff #198451)

These should be SHF_TLS, right? Otherwise, what's the point in testing them in addition to .data?

28–29 ↗(On Diff #198451)

Delete this symbol.

37–39 ↗(On Diff #198451)

Delete this symbol.

test/tools/llvm-nm/linker-synthesized.test
1 ↗(On Diff #198451)

In particular in this test, it would be helpful to have a comment explaining why this test is needed. It may also be useful to have similar comments in the others, although those are clearer.

3 ↗(On Diff #198451)

Couple of nits here:

  1. Blank line between the RUN and yaml blocks, for readability.
  2. You might want to consider moving the checks before the yaml to be consistent with the other tests you wrote.
test/tools/llvm-nm/nonalloc.test
1 ↗(On Diff #198451)

Up to you whether you think it is, but perhaps it would be good to test other debug sections with different flags, e.g. SHF_WRITE?

test/tools/llvm-nm/readonly.test
14–16 ↗(On Diff #198451)

I'd be inclined to have a couple of different rodata sections, with different combinations of flags (i.e. one with just SHF_ALLOC, another with SHF_MERGE and SHF_ALLOC etc).

tools/llvm-nm/llvm-nm.cpp
908–909 ↗(On Diff #198451)

After some experimentation, I discovered that GNU nm (at least version 2.24) has SHF_EXECINSTR as higher priority than the SHT_NOBITS section type, so this should be above the previous if.

This revision now requires changes to proceed.May 8 2019, 2:59 AM
MaskRay updated this revision to Diff 198617.May 8 2019, 3:40 AM
MaskRay marked 11 inline comments as done.

Improve tests suggested by jhenderson

MaskRay marked an inline comment as done.May 8 2019, 3:40 AM
MaskRay added inline comments.
test/tools/llvm-nm/bss.test
1 ↗(On Diff #198451)

Good point to rename it to nobits.test, but I don't think it should test SHF_ALLOC or SHF_EXECINSTR. Their combination with SHT_NOBITS is unrealistic. We can check the precedence here, but I think we should only do it when a use case rises.

test/tools/llvm-nm/data.test
1 ↗(On Diff #198451)

I've thought it for a while. Since we use the real names data.test readonly.test etc for the tests, if the symbols/sections in the tests are realistic seem less important. So I'll go with your suggestion.

test/tools/llvm-nm/nonalloc.test
1 ↗(On Diff #198451)

That will actually belong to my next patch :) I'll try coming up with some tests though I can't think of realistic use cases of symbols pointing to non-allocated non-debug sections.

tools/llvm-nm/llvm-nm.cpp
908–909 ↗(On Diff #198451)

I agree but I'm not sure whether we should check the precedence. SHF_EXECINST+SHT_NOBITS doesn't seem realistic.

jhenderson added inline comments.May 9 2019, 2:37 AM
test/tools/llvm-nm/bss.test
1 ↗(On Diff #198451)

One of the problems we have is that we don't know if the use case exists. I'm inclined to agree with you that the combination is realistic though.

test/tools/llvm-nm/linker-synthesized.test
4 ↗(On Diff #198617)

I think it would be better if the comment is at the top of the file.

Up to you, but I've also seen some people recently using '##' to clearly indicate comments versus lit/FileCheck stuff. It might be nice if you add them, but I don't mind if you don't want to.

If you've got a reference to a reported bug, it would be great to add that.

6–7 ↗(On Diff #198617)

This comment doesn't line up with the behaviour we're testing below...

test/tools/llvm-nm/nobits.test
22 ↗(On Diff #198617)

Perhaps for completeness sake, it's worth adding a local TLS symbol too.

test/tools/llvm-nm/readonly.test
33–35 ↗(On Diff #198617)

Again for completeness, it might be worth adding global versions of all the local symbols. I don't mind too much though.

MaskRay marked 6 inline comments as done.May 9 2019, 2:54 AM
MaskRay added inline comments.
test/tools/llvm-nm/linker-synthesized.test
4 ↗(On Diff #198617)

## is a great idea! It highlights the comments part.

I think it would be better if the comment is at the top of the file.

Perhaps I'm too used to lld tests and there these comments are usually below the RUN lines... I know comments before RUN lines can be regarded as file comments while the comments above may describe the individual tests. In practice, I think there isn't a dichotomy of these two types of comments. I'm ok with either one but inclined to keep it unchanged unless you have strong opinion on this.

test/tools/llvm-nm/nobits.test
22 ↗(On Diff #198617)

I was on the fence about the choice. Since you suggest we go for completeness, I'll do that.

MaskRay updated this revision to Diff 198778.May 9 2019, 2:54 AM
MaskRay marked an inline comment as done.

Address comments

jhenderson accepted this revision.May 9 2019, 4:42 AM

LGTM. Thanks!

This revision is now accepted and ready to land.May 9 2019, 4:42 AM
This revision was automatically updated to reflect the committed changes.