jhenderson added a comment.

In D142660#4541406 <https://reviews.llvm.org/D142660#4541406>, @jhenderson 
wrote:

> In D142660#4538936 <https://reviews.llvm.org/D142660#4538936>, @DiggerLin 
> wrote:
>
>>> As an alternative (but I think adds unnecessary complexity, due to needing 
>>> an extra variable), you could have both tools read the environment variable 
>>> into a string variable, then, if the -X option is present, overwrite that 
>>> variable, and finally feed that string into the parsing code that converts 
>>> into a BitMode value. If the string is invalid, the parsing code could 
>>> report an error along the lines of "invalid OBJECT_MODE or -X option value".
>>
>> if I do not think it is better than my current implement, If I implement as 
>> your suggestion, I need another variable to recoded the where the string 
>> come from(from OBJECT_MODE  or -X option value). otherwise when the invalid 
>> value of string , how can I report it is an invalid OBJECT_MODE"  or 
>> "invalid -X option value"
>
> I'm not convinced you need to distinguish the two. If a user hasn't specified 
> the -X option, then they'll know it's the OBJECT_MODE environment variable. 
> Even if they have both, it should be obvious to a quick glance of the full 
> error message what the wrong value is (because you'd include it in the 
> message) and you could then it won't take long to find which of the two is 
> wrong (even if they don't know that -X trumps OBJET_MODE). That being said, I 
> still prefer the parse OBJECT_MODE first, report an error, then later read 
> the -X option and check for an error there.

It looks like you've ignored this point in your most recent changes. I agree 
that having a variable to say whether the BitMode variable comes from 
OBJECT_MODE or -X is not great, and I'd prefer the `HasAIXOption` style you had 
before over it. However, I'd still rather the invalid OBJECT_MODE value be read 
and rejected upfront before even parsing the -X option.



================
Comment at: llvm/include/llvm/Object/ArchiveWriter.h:44
+enum SymtabWritingMode {
+  NoSymtab,     // Not write Symbol table.
+  NormalSymtab, // Write both 32-bit and 64-bit symbol table.
----------------



================
Comment at: llvm/include/llvm/Object/ArchiveWriter.h:45
+  NoSymtab,     // Not write Symbol table.
+  NormalSymtab, // Write both 32-bit and 64-bit symbol table.
+  Bit32Only,    // Only write the 32-bit symbol table.
----------------
This comment doesn't make sense for non-Big Archive archives, because regular 
archives only have one symbol table. There is no concept of a 32- or 64-bit 
one. Perhaps "Write the symbol table. For the Big Archive format, writes both 
32-bit and 64-bit symbol tables."


================
Comment at: llvm/include/llvm/Object/ArchiveWriter.h:46-47
+  NormalSymtab, // Write both 32-bit and 64-bit symbol table.
+  Bit32Only,    // Only write the 32-bit symbol table.
+  Bit64Only     // Only write the 64-bit symbol table.
+};
----------------
I'd prefix these two with `BigArchive`, or even just name them `BigArchive32` 
and `BigArchive64` respectively, to more clearly convey the fact that they are 
specific to that file format.


================
Comment at: llvm/lib/Object/ArchiveWriter.cpp:966
   if (!isAIXBigArchive(Kind)) {
-    if (WriteSymtab) {
+    if (WriteSymtab != SymtabWritingMode::NoSymtab) {
       if (!HeadersSize)
----------------
Where this comparison is repeated more than once in the same function, it might 
be nice to store the value in a local boolean variable for use in all places 
instead of repeating the comparison.


================
Comment at: llvm/test/tools/llvm-ranlib/non-AIX-not-supportedwq-X-option.test:1
+## REQUIRES: !system-aix
+## Test the -X option is not supported on non-AIX os.
----------------
Looks like there's a typo in your test name?


================
Comment at: llvm/test/tools/llvm-ranlib/non-AIX-not-supportedwq-X-option.test:6
+
+# INVALID-X-OPTION: error: -X32 option not supported on non AIX OS 
----------------
Nit: trailing whitespace


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142660

_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to