[PATCH] D58103: [llvm-readobj] Only allow 4-byte pr_data and refactor GNU_PROPERTY_X86_FEATURE_1_AND processing a bit

George Rimar via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Feb 12 01:24:07 PST 2019


grimar added a comment.

In D58103#1394387 <https://reviews.llvm.org/D58103#1394387>, @MaskRay wrote:

> In D58103#1394386 <https://reviews.llvm.org/D58103#1394386>, @grimar wrote:
>
> > 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.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58103/new/

https://reviews.llvm.org/D58103





More information about the llvm-commits mailing list