[PATCH] D70495: [llvm-readobj/llvm-readelf] - Reimplement dumping of the SHT_GNU_verdef section.
James Henderson via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Fri Nov 22 02:05:52 PST 2019
jhenderson added inline comments.
================
Comment at: llvm/test/tools/llvm-readobj/elf-versioninfo.test:298
+
+## TODO: llvm-readelf also should report a meaningful warning instead of an error.
+# INVALID-LINK-GNU: Version definition
----------------
also should -> should also
is more natural
================
Comment at: llvm/test/tools/llvm-readobj/elf-versioninfo.test:321
+
+# INVALID-STRING-TABLE: warning: '[[FILE]]': SHT_GNU_verdef section: can't use the string table linked: invalid sh_type for string table section [index 0]: expected SHT_STRTAB, but got SHT_NULL
+
----------------
I'd change this to:
sh_link field of SHT_GNU_verdef section at index N is invalid: the section at index 0 is not a string table: expected SHT_STRTAB but got SHT_NULL
================
Comment at: llvm/test/tools/llvm-readobj/elf-versioninfo.test:336
+
+## Check that we report a warning when a SHT_GNU_verdef section is linked with a non-string table section.
+
----------------
This comment doesn't line up with the warning we see below. I'd expect a similar warning to the previous test case.
================
Comment at: llvm/test/tools/llvm-readobj/elf-versioninfo.test:342
+
+# INVALID-DATA: warning: '[[FILE]]': SHT_GNU_verdef section: can't get content: section [index 1] has a sh_offset (0xffffffff) + sh_size (0x0) that cannot be represented
+
----------------
How about "cannot read content of SHT_GNU_verdef section: ..."
I'd ideally put the [index 1] before the colon, i.e. "... of SHT_GNU_verdef section with index 1: the section has a ...", but I'm not sure if that risks losing useful context elsewhere.
================
Comment at: llvm/test/tools/llvm-readobj/elf-versioninfo.test:351-355
+ - Name: .gnu.version_d
+ Type: SHT_GNU_verdef
+ Link: .dynstr
+ Info: 0x0
+ Entries: []
----------------
Nit: this lot all need an extra space of padding to line up with ShOffset.
================
Comment at: llvm/test/tools/llvm-readobj/elf-versioninfo.test:367
+
+# DEF-PAST-END: warning: '[[FILE]]': SHT_GNU_verdef section: version definition 1 goes past the end of the section
+
----------------
invalid SHT_GNU_verdef section with index N: ...
================
Comment at: llvm/test/tools/llvm-readobj/elf-versioninfo.test:398
+
+# AUX-PAST-END: warning: '[[FILE]]': SHT_GNU_verdef section: a version definition 1 refers to an auxiliary entry that goes past the end of the section
+
----------------
invalid SHT_GNU_verdef section with index N: version definition 1 refers ...
================
Comment at: llvm/test/tools/llvm-readobj/elf-versioninfo.test:423
+## Check that we can dump a SHT_GNU_verdef section properly even if it contains version names strings
+## that overruns the string table linked.
+
----------------
overruns -> overrun
the string table linked -> the linked string table
Perhaps worth checking that no warning is printed?
================
Comment at: llvm/test/tools/llvm-readobj/elf-versioninfo.test:473
+
+# UNALIGNED-DEF: warning: '[[FILE]]': SHT_GNU_verdef section: found an unaligned version definition entry
+
----------------
invalid SHT_GNU_verdef section with index N: found a misaligned definition entry at offset X
================
Comment at: llvm/tools/llvm-readobj/ELFDumper.cpp:427-428
+
+ Expected<std::vector<VerDef>> getVersionDefinitions(const ELFFile<ELFT> *Obj,
+ const Elf_Shdr *Sec);
+
----------------
I'm not sure getVersionDefinitions belongs in the DumpStyle class, as it isn't a property of the style. I think it should be moved to the ElfDumper class, along with the other get* functions that are common to both dumping styles.
================
Comment at: llvm/tools/llvm-readobj/ELFDumper.cpp:3954
+
+ // FIXME: this error is untested.
+ if (uintptr_t(VerdauxBuf) % sizeof(uint32_t) != 0)
----------------
grimar wrote:
> MaskRay wrote:
> > We should probably only use FIXME for real code problems. Here we should "TODO".
> >
> > Actually I think the alignment check should be done outside the function. Maybe we should check the alignments of both `VerdefBuf` and `D->vd_aux`.
> > We should probably only use FIXME for real code problems. Here we should "TODO".
> Done.
>
> > Actually I think the alignment check should be done outside the function.
> Done.
>
> >Maybe we should check the alignments of both VerdefBuf and D->vd_aux.
> This is checked already:
> 1) `VerdefBuf` is checked to be 4-bytes aligned.
> 2) I do `VerdauxBuf = VerdefBuf + D->vd_aux` and check `VerdauxBuf`. This checks `D->vd_aux`.
> 3) I do `VerdefBuf += D->vd_next` and check `VerdefBuf`. This checks `D->vd_next`.
>
Is there a reason we can't just test this as part of this change?
================
Comment at: llvm/tools/llvm-readobj/ELFDumper.cpp:3979
+ if (uintptr_t(VerdefBuf) % sizeof(uint32_t) != 0)
+ return createError("SHT_GNU_verdef section: found an unaligned version "
+ "definition entry");
----------------
grimar wrote:
> MaskRay wrote:
> > I guess this should be called "misaligned", not "unaligned", but I am not a native speaker and not very confident about this...
> >
> > Not checking "misaligned auxiliary entry" should be fine.
> > I guess this should be called "misaligned", not "unaligned", but I am not a native speaker and not very confident about this...
>
> Perhaps "misaligned" is correct, since "If something is misaligned, then there's a correct alignment that has not been adhered to" and we have one in mind.
> (https://www.reddit.com/r/grammar/comments/6x1sov/difference_between_unaligned_and_misaligned/)
>
"misaligned" sounds good to me and matches the `LoadVersionNeeds` function.
================
Comment at: llvm/tools/llvm-readobj/ELFDumper.cpp:4020
+ if (!V) {
+ reportWarning(V.takeError(), this->FileName);
+ return;
----------------
Maybe since we now have it, use `reportUniqueWarning`?
================
Comment at: llvm/tools/llvm-readobj/ELFDumper.cpp:5813
+ if (!V) {
+ reportWarning(V.takeError(), this->FileName);
+ return;
----------------
`reportUniqueWarning`?
================
Comment at: llvm/tools/llvm-readobj/ELFDumper.cpp:5828
+ W.printList(
+ "Predecessors", D.AuxV,
+ [](raw_ostream &OS, const VerdAux &Aux) { OS << Aux.Name.c_str(); });
----------------
Do we have any tests for multiple predecessors?
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D70495/new/
https://reviews.llvm.org/D70495
More information about the llvm-commits
mailing list