in the xcoff, if the number of relocation entries or line number entries is overflow(large than or equal 65535) , there will be overflow section for it. The interpret of overflow section is different with generic section header, the patch implement parsing the overflow section.
The same information, when conveyed not via an overflow header, is expressed in decimal format (and not hexadecimal).
According to the XCOFF documentation: The s_relptr and s_lnnoptr fields must have the same values as in the corresponding primary section header.
Since we removed the context of the code line from here, the comment is ambiguous. This should say that, for now, we dump only the section type (low order 16 bits).
Can we encode this into a function (getSectionType(const T &Section)) or constant (SectionFlagsTypeMask) with the comment:
Also, the variable should be named SectionType or similar.
I think we should not be printing a "warning" to the same stream as the output.
"64-bit XCOFF object file".
s/TODO : /TODO /;
Add a blank line here. Also, I am wondering if this should be part of llvm/BinaryFormat/XCOFF.h (perhaps in SectionHeader32, or in a base class thereof when 64-bit support lands).
The "TODO" still has a colon surrounded by spaces on both sides after it. I do not think that we have been using colons after "TODO".
Still missing "and" before "type check section headers".
Still missing "s" after "generic section header".
Typo "seciton" is still present.
Suggestion: "For now we just dump the section type portion of the flags."
LGTM to land as-is. Not sure if other people have an opinion about the const.
@DiggerLin, I believe you have had a number of patches committed into the project. I think you can request commit access and land this yourself. Thanks.
I am not sure that I see a meaningful difference between the functions here that are const and the ones that are not. Given that there are already precedent cases of printing methods of ObjDumper subclasses that are const, I am okay with adding new ones that are const if we have reason to believe they will remain const.
Okay, I agree. Would you mind posting such an NFC patch after this patch lands?
For future reference, I believe we have been using "Oxford commas". That is, a comma before the "and" before (in this case) the third list item, would be appropriate.