This is an archive of the discontinued LLVM Phabricator instance.

[llvm-objdump][XCOFF][AIX] Implement -r option
ClosedPublic

Authored by jasonliu on Feb 25 2020, 11:31 AM.

Details

Summary

Implement several XCOFF hooks to get '-r' option working for llvm-objdump -r.

Diff Detail

Event Timeline

jasonliu created this revision.Feb 25 2020, 11:31 AM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 25 2020, 11:31 AM
jhenderson added inline comments.Feb 28 2020, 1:00 AM
llvm/lib/BinaryFormat/XCOFF.cpp
41

Most architectures use the names R_<ARCH>_... for their relocation names (e.g. R_X86_64_NONE). Is that not the case for XCOFF?

65

This seems fishy. If I was to create a XCOFF object file with a relocation with an unknown type value, would I get this error when e.g. dumping relocations?

My feeling is that anything that uses report_fatal_error is a bug waiting to happen. Better would be to return some string indicating an unknown relocation type.

llvm/lib/Object/XCOFFObjectFile.cpp
322–330

Does other code further up the stack check to make sure the file is not 64 bits? If not, this isn't a valid assertion, since the program could reach this point. What would happen then if assertions are disabled?

Same comment goes for all the other instances of this.

364

Is this really unreachable? Could you get to here with an object with some invalid relocation or section property?

372

clang-format. But should this really be an assertion rather than an llvm::Error or similar?

llvm/test/CodeGen/PowerPC/aix-xcoff-reloc.ll
450

Nit: remove the second blank line.

This looks great, thanks Jason!

llvm/lib/BinaryFormat/XCOFF.cpp
41

according this document these names are correct as they currently are. https://www.ibm.com/support/knowledgecenter/ssw_aix_72/filesreference/XCOFF.html#XCOFF__sua3i125jbau

65

ELF returns the string "Unknown". Will make it less painful in case this code falls out of sync with new relocs.

llvm/lib/Object/XCOFFObjectFile.cpp
364

Agree. I think a relocation with an invalid r_vaddr could fall through this.

DiggerLin added inline comments.Feb 28 2020, 1:09 PM
llvm/lib/BinaryFormat/XCOFF.cpp
65

for enum type , if your switch case has enumerate all the case,
please do not use the default, otherwise it will cause a compiler error with clang

llvm/tools/llvm-objdump/XCOFFDump.cpp
26

I think you can use function unwrapOrError()
something like
StringRef SymbolName =

unwrapOrError(Obj.getFileName(), Obj.getSymbolName(SymbolDRI));
jasonliu marked 4 inline comments as done.Feb 28 2020, 1:18 PM
jasonliu added inline comments.
llvm/lib/Object/XCOFFObjectFile.cpp
322–330

I agree. I will make them all report_fatal_error instead of assertion.

364

I see. I could make them report_fatal_error instead.

davidb added inline comments.Feb 28 2020, 3:42 PM
llvm/include/llvm/BinaryFormat/XCOFF.h
261

Suggestion to match the other BinaryFormats getRelocationTypeString -> getRelocationTypeName

261

Actually I take it back... I see both symbols are used for targets

jhenderson added inline comments.Mar 2 2020, 12:49 AM
llvm/lib/BinaryFormat/XCOFF.cpp
65

for enum type , if your switch case has enumerate all the case,

please do not use the default, otherwise it will cause a compiler error with clang

Does this apply for all enum variations? It's trivially easy to cast something such that it isn't a recognised value.

Regardless, in this context, you can easily return outside the switch.

llvm/lib/Object/XCOFFObjectFile.cpp
322–330

I consider report_fatal_error to be as bad as an assertion for code that can get to here, as the error is useless and implies an internal problem in llvm, which isn't true if it's only hit due to malformed input. If at all possible, I'd recommend using llvm::Expected to report errors, if it's possible within the interface (what do other ObjectFile variations do?).

364

See my earlier comment. Please use llvm::Expected if possible, not report_fatal_error.

jasonliu marked an inline comment as done.Mar 9 2020, 11:41 AM
jasonliu added inline comments.
llvm/lib/Object/XCOFFObjectFile.cpp
322–330

I think the report_fatal_error is appropriate here. In here, we do imply there is an internal problem in llvm for XCOFF object file, as our tooling do not support parsing 64 bit object yet (not that the input object file is malformed input).

jasonliu marked 4 inline comments as done.Mar 9 2020, 3:31 PM
jasonliu added inline comments.
llvm/lib/Object/XCOFFObjectFile.cpp
372

Ideally, we should return llvm::Expect<symbol_iterator> for this function. But if we do that, it would be a very big interface change across the board. We need to return llvm::Expect<symbol_iterator> for RelocationRef's getSymbol() as well, and there are several dozens of places used RelocationRef's getSymbol() method.

For other object files, they would return symbol_end(), and I think it would make more sense to follow suit in this case.

jasonliu marked an inline comment as done.Mar 10 2020, 8:18 AM
jasonliu added inline comments.
llvm/lib/Object/XCOFFObjectFile.cpp
364

As mentioned below, I find it a bit challenge to change the existing interface to return llvm::Expected. Although this one might not be as hard as getRelocationSymbol, it is still a non-trivial task after some investigation (i.e. there are python script actually depending on existing interface if I'm not mistaken). So I'm thinking to proceed with some less resistant way.

Other target for this function will return the virtual address stored in the relocation entry without checking and calculation.
Presumably, the caller of this function would have to check if the range is valid, or they would just happy to accept any invalid value and print it.
So my plan is, for XCOFF target, we could return a magic number (std::numeric_limits<uint64_t>::max()) so that if anyone bother to check the range, they know it's invalid, and if they don't want to check it, they could still proceed gracefully just like other target.

jasonliu updated this revision to Diff 249401.Mar 10 2020, 8:50 AM
jasonliu marked 2 inline comments as done.

Address comments.

llvm/tools/llvm-objdump/XCOFFDump.cpp
26

unwrapOrError is not suitable for this interface when we actually want to propagate the llvm::Error to the caller.

@jhenderson @davidb @DiggerLin
Thanks for all the comments. I have updated the patch, and you are welcome to review again anytime.
Thanks again.

DiggerLin added inline comments.Mar 11 2020, 8:48 AM
llvm/tools/llvm-objdump/XCOFFDump.cpp
23

what happen if the SymI point to symbol_end() ?

jasonliu updated this revision to Diff 249676.Mar 11 2020, 10:36 AM

Updated to return error when receiving a symbol_end().

jasonliu marked an inline comment as done.Mar 11 2020, 10:36 AM
jasonliu added inline comments.
llvm/tools/llvm-objdump/XCOFFDump.cpp
23

We will return error for it. Thanks for point it out.

jasonliu updated this revision to Diff 249682.Mar 11 2020, 10:44 AM
This revision is now accepted and ready to land.Mar 16 2020, 10:21 AM
llvm/lib/Object/XCOFFObjectFile.cpp
324

Please replace Typename* binding with Declarator *binding.

llvm/lib/BinaryFormat/XCOFF.cpp
36

This does not follow the convention of placing the backslash on the same column for all lines of a macro definition.

llvm/lib/Object/XCOFFObjectFile.cpp
26–27

This should be in an anonymous namespace if a drive-by fix is okay.

30

The types associated with these constants do not appear to be uniform. It does not appear that these should be all enumerators of the same enumeration type.

jhenderson requested changes to this revision.Mar 17 2020, 2:20 AM
jhenderson added inline comments.
llvm/lib/BinaryFormat/XCOFF.cpp
65

Sounds good to me.

llvm/lib/Object/XCOFFObjectFile.cpp
322–330

I had a look at what other object files do. In ELF, an error is simply thrown away and a null iterator is constructed. In COFF, a report_fatal_error is reached. Mach-O and wasm both don't have any errors.

I'm not happy about the current state, but I suppose there's prior art and it needs a bigger cleanup anyway. Plus, once 64-bit is implemented, this goes away.

323

Here and all report_fatal_error calls: remove the trailing full stop.

324

Isn't this handled by clang-format?

364

I had a play around with this. I think a change in the interface is viable, and not all that invasive, with an issue in the llvm-c level being the only one that stopped me trying to push the change further for now.

UINT64_MAX is probably a better value than zero, I suppose. I'm not massively happy with it, since technically, there's nothing stopping a single-byte-patching relocation patching the very last value in a massive ELF. However, in practice that's never going to happen.

Could you put the value as a static constant in the XCOFF object file, and then refer to it elsewhere? That would at least ensure the meaning of the value is clear. You'd want to mention that it returns the constant in the function's doxygen comment.

366–367

If you pull the value into a named constant, you won't need this comment.

llvm/tools/llvm-objdump/XCOFFDump.cpp
25–26

Errors usually have lower case first letter and no trailing full stop.

This revision now requires changes to proceed.Mar 17 2020, 2:20 AM
llvm/lib/Object/XCOFFObjectFile.cpp
323

We have been trying to full stops for XCOFF work for invocations of report_fatal_error, llvm_unreachable, and assert in order to be consistent within our patches and after having observed that such uses are not uncommon.

For example:

llvm/lib/Object/COFFObjectFile.cpp:    report_fatal_error("Section was outside of section table.");
llvm/lib/Object/COFFObjectFile.cpp:      report_fatal_error("Aux Symbol data was outside of symbol table.");
llvm/lib/Object/MachOObjectFile.cpp:    report_fatal_error("Malformed MachO file.");
llvm/lib/Object/MachOObjectFile.cpp:    report_fatal_error("Requested symbol index is out of range.");
324

It does for me now. I'm not certain it always did so in the past.

llvm/tools/llvm-objdump/XCOFFDump.cpp
25–26

Thanks for pointing this out. We will correct this.

llvm/lib/Object/XCOFFObjectFile.cpp
336

clang-format here too. Please check throughout the patch.

359

I believe it is more idiomatic to place the range boundaries on either end of the comparison:

Sec32->VirtualAddress <= RelocAddress && RelocAddress < (Sec32->VirtualAddress + Sec32->SectionSize)
363

I believe it is customary to use prefix increment when possible: https://llvm.org/docs/CodingStandards.html#prefer-preincrement

385

Minor nit: Functions that can be "simple one-liners" should be written as such.
The 64-bit part aside, we can have just the return statement.

The overhead of the declaration for Reloc is a large proportion of this function, especially considering its (lack of) utility here.

llvm/tools/llvm-objdump/XCOFFDump.cpp
2

Line exceeds 80 columns.

llvm/tools/llvm-objdump/XCOFFDump.cpp
25

Suggestion:
"invalid symbol reference in relocation entry"

jasonliu updated this revision to Diff 250939.Mar 17 2020, 4:15 PM
jasonliu marked 16 inline comments as done.

@jhenderson @hubert.reinterpretcast
Thanks, James and Hubert. I believe I addressed all your comments.

jasonliu marked 2 inline comments as done.Mar 17 2020, 4:19 PM
llvm/include/llvm/Object/XCOFFObjectFile.h
282–287

Please add a blank line before the comment block.

283

Suggestion:
Returns the relocation offset with the base address of the containing section as zero.

284

Suggestion:
Returns <named constant> on errors (such as a relocation that does not refer to an address in any section).

llvm/lib/Object/XCOFFObjectFile.cpp
22

My understanding of @jhenderson's comment is that this should be an interface constant in a header.

jasonliu updated this revision to Diff 251073.Mar 18 2020, 7:10 AM
jasonliu marked 4 inline comments as done.
jasonliu updated this revision to Diff 251074.Mar 18 2020, 7:14 AM

I believe all of the previous comments have been addressed or discussed. I have just some minor comments.

llvm/include/llvm/Object/XCOFFObjectFile.h
18

I'm not a fan of increasing inclusions in an interface header.

251

0xffffffff'ffffffffULL

jasonliu updated this revision to Diff 251094.Mar 18 2020, 8:29 AM
jasonliu marked 2 inline comments as done.

Thanks Jason. This LGTM.

MaskRay retitled this revision from [XCOFF][AIX] Enable -r option for llvm-objdump to [llvm-objdump][XCOFF][AIX] Implement -r option.Mar 19 2020, 10:44 AM
MaskRay added inline comments.Mar 19 2020, 10:52 AM
llvm/lib/Object/XCOFFObjectFile.cpp
22

Is the anonymous namespace useful?

llvm/test/tools/llvm-objdump/xcoff-disassemble-all.test
1

Rebase and move it to XCOFF/disassemble-all.test

The hierarchy of llvm-objdump test files follows llvm-readobj/llvm-objcopy now.

MaskRay added inline comments.Mar 19 2020, 10:53 AM
llvm/include/llvm/Object/XCOFFObjectFile.h
251

Will UINT64_C(-1) be clearer?

jasonliu marked an inline comment as done.Mar 19 2020, 12:26 PM
jasonliu added inline comments.
llvm/lib/Object/XCOFFObjectFile.cpp
22

I think it's good for internal linkage, and make it unreachable from other translation units.

llvm/include/llvm/Object/XCOFFObjectFile.h
251

You mean -UINT64_C(1)? I don't think so. My experience is that people are not familiar with these macros.

llvm/lib/Object/XCOFFObjectFile.cpp
16

@jasonliu: Is the <limits> inclusion still needed?

22
jasonliu updated this revision to Diff 251473.Mar 19 2020, 2:11 PM
jasonliu marked an inline comment as done.

Remove <limits> and rebase.

jhenderson added inline comments.Mar 20 2020, 2:19 AM
llvm/include/llvm/Object/XCOFFObjectFile.h
251

I would use std::numeric_limits<uint64_t>::max(), since it's clearer to me than a literal. It's meaning seems obvious.

284–287

Please reflow this comment so that it isn't weirdly spaced (especially the end of the third line).

I'd actually recommend another change too:

"\returns the relocation offset with the base address of the containing section as zero, or InvalidRelocOffset on error (for example for a relocation that does not refer to an address in any section)."

The "\returns" style is a doxygen thing.

llvm/lib/Object/XCOFFObjectFile.cpp
25–27

At this point would it just make more sense to make these static constant literals?

// TODO: Use appropriate naming convention - are these spec-defined, or just local names?
static const int RELOC_OVERFLOW = 65535; // Use an appropriate type here.
static const uint8_t FUNCTION_SYM = 0x20;
static const uint8_t SYM_TYPE_MASK = 0x07;
static const uint16_t NO_REL_MASK = 0x0001;
323

They may not be uncommon, because people haven't been particularly careful with how they write error messages in the past. Whereever possible, I've tried to encourage people to adopt a single consistent style - note that most (all?) of our error messages in clang, LLD and various tools like llvm-readobj and llvm-objdump use lower-case and no trailing full stop. report_fatal_error calls should be no different.

360

I'm pretty certain you don't need the parentheses here.

llvm/test/tools/llvm-objdump/XCOFF/disassemble-all.test
1–5 ↗(On Diff #251473)

Please don't test -r + -D instead of -D on its own. -D should be tested on its own. -r should be tested on its own in a separate test. I'd also recommend -r + -d be tested there too (or that could even be a different test file if you want).

jasonliu marked 2 inline comments as done.Mar 20 2020, 7:27 AM
jasonliu added inline comments.
llvm/include/llvm/Object/XCOFFObjectFile.h
251

This was my original implementation, I don't have anything against it.

@hubert.reinterpretcast Any comments?

llvm/lib/Object/XCOFFObjectFile.cpp
25–27

This was a drive-by fix because I touched this line when I want to put in InvalidRelocOffset. Now, it's irrelevant to the current patch, and I will put it to its original state.

llvm/include/llvm/Object/XCOFFObjectFile.h
251

I was hoping to not add an extra header inclusion to an interface file, but readability concerns are more important. @jasonliu, sorry for the churn.

llvm/lib/Object/XCOFFObjectFile.cpp
323

@jhenderson, I agree that a single consistent style would be great. I note that the Coding Standards do not document this style. It is also unfortunate that this style is not consistent, in respect to the capitalization of the first word, with the examples in the Coding Standards for strings in assert and llvm_unreachable. If you find consensus to update the Coding Standards to document this style, it would probably help to improve the consistency in the project.

MaskRay added inline comments.Mar 20 2020, 8:37 AM
llvm/lib/Object/XCOFFObjectFile.cpp
323

Please stop capitalizing and stop using a trailing full stop. For the common infrastructure of LLVMObject and binary utilities where James and several other contributors spending a lot of time on, we have made lots of efforts improving the diagnostics and their consistency. As a relatively new user of these infrastructure, it'd be much appreciated if XCOFF could follow suite. I hope this XCOFF development in Object won't be sort of code dump.

MaskRay requested changes to this revision.Mar 20 2020, 8:37 AM
This revision now requires changes to proceed.Mar 20 2020, 8:37 AM
jasonliu marked an inline comment as done.Mar 20 2020, 8:55 AM
jasonliu added inline comments.
llvm/lib/Object/XCOFFObjectFile.cpp
323

We are good with the consistent style. And I will make the change. We are just asking if it make sense to update Coding Standards to document the style as right now it's not all consistent through out the project, and it's easy to follow the wrong precedent.

I hope this XCOFF development in Object won't be sort of code dump.

I don't find this comment to be very constructive.

llvm/lib/Object/XCOFFObjectFile.cpp
323

I believe that this is the first patch for which we were told about this convention. No one had said we were not changing this after James indicated that he believes it to be an important point. I find the insinuation that a "code dump" is being attempted to be rather extreme.

jasonliu updated this revision to Diff 251700.Mar 20 2020, 10:44 AM
jasonliu marked 5 inline comments as done.

Remove trailing stop on report_fatal_error and various comment addressed.

llvm/lib/Object/XCOFFObjectFile.cpp
25–27

Sorry, just realized that NO_REL_MASK is the reason I need to do the drive-by fix and it's still needed. So I will use the static const instead.

Thanks for all the constructive comments.
@jhenderson @MaskRay Let me know if current revision looks good to you.

MaskRay accepted this revision.Mar 20 2020, 11:29 AM
MaskRay added inline comments.
llvm/test/tools/llvm-objdump/XCOFF/disassemble-all.test
66 ↗(On Diff #251700)

It may look slightly better if you add enough spaces after : to make the first letter on the right of CHECK-D-r-NEXT:

jhenderson added inline comments.Mar 23 2020, 2:41 AM
llvm/lib/Object/XCOFFObjectFile.cpp
323

Thanks for making the change. I'll post a question on llvm-dev about whether we should update the coding standard. I guess assert and llvm_unreachable are a little different, because of how they are printed. I'll do some investigation and write a full proposal up.

llvm/test/tools/llvm-objdump/XCOFF/disassemble-all.test
2 ↗(On Diff #251700)

Indent continuation lines by two extra spaces to show they are clearly continuations:

# RUN: llvm-objdump -D %p/Inputs/xcoff-section-headers.o | \
# RUN:   FileCheck %s

I'm suggesting it for all the checks.

10–11 ↗(On Diff #251700)

As mentioned, I think this case should be moved to a different test file, as it's really testing something unrelated.

66 ↗(On Diff #251700)

I'd recommended using FileCheck's --check-prefixes option to fold these two sequences together, as it will more clearly show the differences.

Example:

# RUN: llvm-objdump -D %p/Inputs/xcoff-section-headers.o | \
# RUN:   FileCheck %s

# RUN: llvm-objdump -D -r %p/Inputs/xcoff-section-headers.o | \
# RUN:   FileCheck %s --check-prefixes=CHECK,WITH-R

CHECK:       Inputs/xcoff-section-headers.o:  file format aixcoff-rs6000
CHECK:       Disassembly of section .text:
CHECK:       00000000 <.text>:
CHECK-NEXT:         0: 80 62 00 04                    lwz 3, 4(2)
WITH-R-NEXT:                         00000002:  R_TOC       
CHECK-NEXT:         4: 80 63 00 00                    lwz 3, 0(3)
jasonliu updated this revision to Diff 252040.Mar 23 2020, 7:52 AM
jasonliu marked 5 inline comments as done.

Address comments on test.

llvm/lib/Object/XCOFFObjectFile.cpp
323

Thanks for the effort. Appreciate it.

llvm/test/tools/llvm-objdump/XCOFF/disassemble-all.test
23 ↗(On Diff #252040)

I think additional prefixes can be added for the .text part to common up the -D -r and the -d -r.

jasonliu marked an inline comment as done.Mar 23 2020, 3:23 PM
jasonliu added inline comments.
llvm/test/tools/llvm-objdump/XCOFF/disassemble-all.test
23 ↗(On Diff #252040)

Common up for the two cases make sense as they are identical for 95% of the time right now, and does not need much effort to parse both of the them.
Common up for all three cases and adding more prefix actually decrease the readability of the test case in my mind.
So if people are not feeling strong about it, I'd prefer to leave it as it is.

llvm/test/tools/llvm-objdump/XCOFF/disassemble-all.test
23 ↗(On Diff #252040)

Just for sketching out the effect, the end result would be using:
TEXT,ALL,ALL-NO-R
TEXT,ALL,TEXT-R,ALL-R
TEXT,TEXT-R

With:

TEXT:        Inputs/xcoff-section-headers.o:  file format aixcoff-rs6000
TEXT:        Disassembly of section .text:
TEXT:        00000000 <.text>:
TEXT-NEXT:        0: 80 62 00 04                    lwz 3, 4(2)
TEXT-R-NEXT:                         00000002:  R_TOC        a
TEXT-NEXT:        4: 80 63 00 00                    lwz 3, 0(3)
TEXT-NEXT:        8: 4e 80 00 20                    blr
TEXT-NEXT:        c: 00 00 00 00                    <unknown>
TEXT-NEXT:       10: 00 00 20 40                    <unknown>
TEXT-NEXT:       14: 00 00 00 01                    <unknown>
TEXT-NEXT:       18: 00 00 00 0c                    <unknown>
TEXT-NEXT:       1c: 00 04 66 75                    <unknown>
TEXT-NEXT:       20: 6e 63 00 00                    xoris 3, 19, 0
TEXT-NEXT:   ...
ALL:         Disassembly of section .data:
ALL:         00000080 <func>:
ALL-NEXT:        80: 00 00 00 94                    <unknown>
ALL:         00000084 <a>:
ALL-NEXT:        84: 00 00 00 a4                    <unknown>
ALL:         00000088 <b>:
ALL-NEXT:        88: 00 00 00 a0                    <unknown>
ALL:         0000008c <c>:
ALL-NEXT:        8c: 00 00 00 08                    <unknown>
ALL:         00000090 <d>:
ALL-NO-R-NEXT:   90: 00 00 00 00                    <unknown>
ALL-R-NEXT:  ...
ALL:         00000094 <func>:
ALL-NEXT:        94: 00 00 00 00                    <unknown>
ALL-NEXT:        98: 00 00 00 80                    <unknown>
ALL-NEXT:        9c: 00 00 00 00                    <unknown>
ALL:         000000a0 <b>:
ALL-NEXT:        a0: 00 00 30 39                    <unknown>
ALL:         Disassembly of section .bss:
ALL:         000000a4 <a>:
ALL-NEXT:    ...
ALL:         Disassembly of section .tdata:
ALL:         00000000 <d>:
ALL-NEXT:         0: 40 09 21 f9                    bdnzfl  9, .+8696
ALL-NEXT:         4: f0 1b 86 6e                    <unknown>
ALL:         Disassembly of section .tbss:
ALL:         00000008 <c>:
ALL-NEXT:    ...
llvm/test/tools/llvm-objdump/XCOFF/print-reloc.test
2 ↗(On Diff #252040)

Minor nit: No need to use a --check-prefix now that this is a separate file.

jasonliu marked 2 inline comments as done.Mar 24 2020, 7:18 AM
jasonliu added inline comments.
llvm/test/tools/llvm-objdump/XCOFF/disassemble-all.test
23 ↗(On Diff #252040)

Thanks for generating the proposed result.
Comparing it side by side confirms my worries... It took extra effort to understand what each test expects, comparing the current one we have right now.

llvm/test/tools/llvm-objdump/XCOFF/print-reloc.test
2 ↗(On Diff #252040)

Thanks. I will address it in the commit if I don't receive other comments.

hubert.reinterpretcast marked an inline comment as done.

Just confirming that this LGTM (with the minor comment posted before). Please wait to see if @jhenderson agrees that his comments have been addressed.

llvm/test/tools/llvm-objdump/XCOFF/disassemble-all.test
23 ↗(On Diff #252040)

Okay, thanks for looking.

Thanks for the effort. This is nearly there.

llvm/test/tools/llvm-objdump/XCOFF/disassemble-all.test
7–8 ↗(On Diff #252040)

-d -r should be tested in a test for the --disassemble option, not --disassemble-all. Arguably in fact, you don't need it tested at all, as the -D -r combination is probably sufficient.

23 ↗(On Diff #252040)

So I think the question is really, what is the purpose of the test? Is it to allow easy comparison of two outputs or something else? As things stand, it isn't easy to compare said two outputs.

This is of course slightly moot, since there really should only be two test cases in this file anyway (see my comment above).

llvm/test/tools/llvm-objdump/XCOFF/print-reloc.test
2 ↗(On Diff #252040)

You should probably add --match-full-lines and --strict-whitespace to this FileCheck call, especially the former of these. This might require you to do some extra indentation stuff to make things look okay (see below - it ensures that all output lines up):

     RELOC:Inputs/xcoff-section-headers.o:  file format aixcoff-rs6000
     RELOC:RELOCATION RECORDS FOR [.text]:
RELOC-NEXT:OFFSET   TYPE                     VALUE
RELOC-NEXT:00000002 R_TOC                    a
     RELOC:RELOCATION RECORDS FOR [.data]:
RELOC-NEXT:OFFSET   TYPE                     VALUE
...
4–14 ↗(On Diff #252040)

Use '##' for comments.

16 ↗(On Diff #252040)

';' -> '#' for consistency with other lit directives. Also, this should be at the top of the file as is common for REQUIRES directives.

20 ↗(On Diff #252040)

Add RELOC-EMPTY here and after the last relocation in the other block to show that all relocations have been printed.

llvm/test/tools/llvm-objdump/XCOFF/disassemble-all.test
10 ↗(On Diff #252040)

Since the ##-for-comments was mentioned for the new test file, we might as well fix this one?

21 ↗(On Diff #252040)

Same as for the REQUIRES line for the new test file.

jasonliu updated this revision to Diff 252597.Mar 25 2020, 9:14 AM
jasonliu marked 6 inline comments as done.
jhenderson accepted this revision.Mar 26 2020, 2:14 AM

LGTM, once my last comment has been addressed and question answered (assuming that the question doesn't highlight an issue in the patch itself). Thanks for putting up with my lengthy review!

llvm/test/tools/llvm-objdump/XCOFF/disassemble-all.test
45–46 ↗(On Diff #252597)

I find this behaviour difference confusing. What is causing it?

llvm/test/tools/llvm-objdump/XCOFF/print-reloc.test
30 ↗(On Diff #252597)

Still need a CHECK-EMPTY: at the end here.

This revision is now accepted and ready to land.Mar 26 2020, 2:14 AM
jasonliu marked 2 inline comments as done.Mar 26 2020, 7:41 AM
jasonliu added inline comments.
llvm/test/tools/llvm-objdump/XCOFF/disassemble-all.test
45–46 ↗(On Diff #252597)

This block of code kicks in:

if (!DisassembleZeroes) {
  uint64_t MaxOffset = End - Index;
  // For -reloc: print zero blocks patched by relocations, so that
  // relocations can be shown in the dump.
  if (RelCur != RelEnd)
    MaxOffset = RelCur->getOffset() - Index;

  if (size_t N =
          countSkippableZeroBytes(Bytes.slice(Index, MaxOffset))) {
    outs() << "\t\t..." << '\n';
    Index += N;
    continue;
  }
}

The MaxOffset is larger when we have relocation. So we start to print '...' for that.

In this file, you might think there is no relocation showing up after line 25. But it's actually there if we check the new print-reloc.test. The reason llvm-objdump is not printing them is because of this patch: https://reviews.llvm.org/D73531. Since we could not disassemble those instructions in the data section, we decide not to analysis them and skipped the relocation printing. This skip printing relocation is not ideal for XCOFF as you could see, but I would like to address it in a different patch.

llvm/test/tools/llvm-objdump/XCOFF/print-reloc.test
30 ↗(On Diff #252597)

Thanks. I will address it in the commit if there is no other comment.

jasonliu marked an inline comment as done.Mar 26 2020, 7:59 AM
jasonliu added inline comments.
llvm/test/tools/llvm-objdump/XCOFF/disassemble-all.test
45–46 ↗(On Diff #252597)

To elaborate why MaxOffset is larger when we have relocation:
RelCur is pointing at the relocation of <func> when we are at <d>, and offset of func is 0, with RelCur->getOffset() - Index, it wraps around becomes a very large number, which is not right.

This revision was automatically updated to reflect the committed changes.
Via Web