The patch adds support for dumping auxiliary symbols in llvm-readobj for XCOFF.
Details
- Reviewers
shchenz qiucf jhenderson jsji Higuoxing - Group Reviewers
Restricted Project - Commits
- rGaad49c8eb984: [llvm-readobj][XCOFF] dump auxiliary symbols.
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I recommend separating the migration to YAML from binaries into a separate successor patch, to avoid confusion.
llvm/test/tools/llvm-readobj/XCOFF/symbols-invalid.test | ||
---|---|---|
6 | How about "a non-function C_EXT/C_WEAKEXT/C_HIDEXT symbol should have only..."? You probably should have this test case for each of the three different types. If viable, I'd also dynamically change the warning to explicitly state the type of the symbol (i.e. something like "a non-function C_EXT symbol ..." and "a non-function C_WEAKEXT symbol ..." etc). Finally, ideally you'd incldue the symbol's name if possible in this warning, since it's not necessarily clear out-of-context which symbol this warning refers to. Applies to each of the other warnings too. | |
20 | Nit: double blank line. | |
30 | Same as above: test both cases, adn consider being explicity about which particular type of symbol this is. | |
32 | Why specifically the file auxiliary entry and not others? | |
llvm/tools/llvm-readobj/XCOFFDumper.cpp | ||
289 | ||
428 | Why do we only check this in the debug case? It seems like it's something that's applicable for all cases? | |
433 | Unless you're explicitly calling printf (which you aren't) don't call a function based on that name. | |
501–504 | Skip doing what? |
llvm/include/llvm/Object/XCOFFObjectFile.h | ||
---|---|---|
375–379 | It looks that the variables' name are not consistent across this file? Is there any particular reason for that? e.g., Why use ReservedZeros_1 instead of ReservedZeros1 and LineNum_Hi instead of LineNumLo? | |
llvm/test/tools/llvm-readobj/XCOFF/symbols-invalid.test | ||
63–66 | Looks that the indention is broken here? | |
llvm/tools/llvm-readobj/XCOFFDumper.cpp | ||
333–334 | Nit: insert a blank space between the field name and the parenthesis. | |
350 | Nit: blank line. |
llvm/test/tools/llvm-readobj/XCOFF/symbols-invalid.test | ||
---|---|---|
6 | It looks like you haven't addressed the first part of this comment? | |
llvm/tools/llvm-readobj/XCOFFDumper.cpp | ||
503 | Should have spotted this earlier, but it should be "at index N" not "with index N". Same goes for the other message(s). | |
587 | I wonder if a simple function that converts enum values to strings would be useful here and elsewhere that you do similar things? I believe there are similar things in ELF. |
llvm/test/tools/llvm-readobj/XCOFF/symbols-invalid.test | ||
---|---|---|
52–66 | You can leave the # in the right place, and just add spaces to pad. | |
llvm/tools/llvm-readobj/XCOFFDumper.cpp | ||
67 | I'm slightly surprised this doesn't already exist in our code? Have you copied it from somewhere? If so, where, and could you just move such a function declaration into a common header for reuse? |
llvm/lib/Object/XCOFFObjectFile.cpp | ||
---|---|---|
1116–1117 | Is "should" appropriate here? Is it never a function? Or is it potentially a function that we can't identify? If the former, delete the word. If the latter, replace the phrase "then this symbol should not be a function" with "then treat this symbol as if it isn't a function". | |
llvm/tools/llvm-readobj/XCOFFDumper.cpp | ||
525 | No need for else after continue | |
565–567 | There are several checks identical to this one. I think it would be useful to pull them into a helper lambda that takes a C_* enum and reports the message. |
This breaks tests on windows: http://45.33.8.238/win/52389/step_11.txt
Please take a look and revert for now if it takes a while to fix.
llvm/test/tools/llvm-readobj/XCOFF/symbols-invalid.test | ||
---|---|---|
6 | The problem is a missing {{(.exe)?}} after the tool name. Usually, we don't include tool names in the check, and just check from "warning:" onwards. Applies throughout this test. |
llvm/test/tools/llvm-readobj/XCOFF/symbols-invalid.test | ||
---|---|---|
6 | Hm, normally we don't print "toolname.exe: " in diags on Windows, but just "toolname: ". We usually also don't print the full path to the tool but just the basename. Maybe the Right Fix is to fix the diag output in llvm-readobj instead? | |
6 | (…but that seems admittedly mostly independent of this patch here. So for relanding, just fixing the test expectations is fine too.) |
It looks that the variables' name are not consistent across this file? Is there any particular reason for that? e.g., Why use ReservedZeros_1 instead of ReservedZeros1 and LineNum_Hi instead of LineNumLo?