This is an archive of the discontinued LLVM Phabricator instance.

[llvm-readobj] Only allow 4-byte pr_data
ClosedPublic

Authored by MaskRay on Feb 11 2019, 11:27 PM.

Details

Summary

AMD64 psABI says: "The pr_data field of each property contains a 4-byte unsigned integer." Thus we don't need to handle 8-byte pr_data.

Diff Detail

Repository
rL LLVM

Event Timeline

MaskRay created this revision.Feb 11 2019, 11:27 PM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 11 2019, 11:27 PM

Yes, there is a similar patch for the data size in https://reviews.llvm.org/D56080, which deal with the size in X86 llvm asmprint.

Yes, there is a similar patch for the data size in https://reviews.llvm.org/D56080, which deal with the size in X86 llvm asmprint.

So it is always 4, correct? I just checked binutils-gdb and it also uses fixed 4.

Looks correct, FTR ABI link is https://github.com/hjl-tools/x86-psABI/wiki/x86-64-psABI-draft.pdf.

Regarding the refactoring, in my opinion, the original code was simpler. I would leave it as is.
(at least refactoring change could be in a separate patch, if you want to do it)

Looks correct, FTR ABI link is https://github.com/hjl-tools/x86-psABI/wiki/x86-64-psABI-draft.pdf.

Regarding the refactoring, in my opinion, the original code was simpler. I would leave it as is.
(at least refactoring change could be in a separate patch, if you want to do it)

For GNU_PROPERTY_X86_FEATURE_1_AND, there are only 2 bits. When people start implementing
GNU_PROPERTY_X86_ISA_1_USED GNU_PROPERTY_X86_ISA_2_USED GNU_PROPERTY_X86_COMPAT_ISA_1_USED, this style will become better :)

Yes it is always 4 now

Looks correct, FTR ABI link is https://github.com/hjl-tools/x86-psABI/wiki/x86-64-psABI-draft.pdf.

Regarding the refactoring, in my opinion, the original code was simpler. I would leave it as is.
(at least refactoring change could be in a separate patch, if you want to do it)

For GNU_PROPERTY_X86_FEATURE_1_AND, there are only 2 bits. When people start implementing
GNU_PROPERTY_X86_ISA_1_USED GNU_PROPERTY_X86_ISA_2_USED GNU_PROPERTY_X86_COMPAT_ISA_1_USED, this style will become better :)

There are different ways to do a refactoring here. For example, it could probably be:

auto DumpFlag = [](StringRef Name, uint64_t Flag, uint32_t &Val) {
  if (Val & Flag) {
    Val &= ~Flag;
    OS << Name;
    if (Val)
      OS << ", ";
  }
};

DumpFlag("IBT", GNU_PROPERTY_X86_FEATURE_1_IBT, pr_data);
DumpFlag("SHSTK", GNU_PROPERTY_X86_FEATURE_1_SHSTK, pr_data);

Which still looks simpler to me, but you or other people might disagree,
so probably it is better to discuss the refactoring in a different review.

My main point is that functional and refactoring changes
should not be mixed in the same patch.

MaskRay updated this revision to Diff 186415.Feb 12 2019, 1:31 AM
MaskRay retitled this revision from [llvm-readobj] Only allow 4-byte pr_data and refactor GNU_PROPERTY_X86_FEATURE_1_AND processing a bit to [llvm-readobj] Only allow 4-byte pr_data.

Remove refactoring

grimar accepted this revision.Feb 12 2019, 1:39 AM

LGTM

This revision is now accepted and ready to land.Feb 12 2019, 1:39 AM
This revision was automatically updated to reflect the committed changes.

Your approach looks great! Moved the refactoring part (I also have to implement GNU_PROPERTY_X86_FEATURE_2_{NEEDED,USED} to demonstrate the idea) to D58112