This is an archive of the discontinued LLVM Phabricator instance.

[XCOFF] Add functionality for parsing AIX XCOFF object files header .
ClosedPublic

Authored by DiggerLin on Mar 15 2019, 9:14 AM.

Details

Summary
  1. Add functionality for parsing AIX XCOFF object files header .
  2. Only support 32bits AIX XCOFF object files in the patch
  3. Print out the AIX XCOFF object file header as YAML format.

Diff Detail

Event Timeline

DiggerLin created this revision.Mar 15 2019, 9:14 AM
DiggerLin retitled this revision from [llvm] Add functionality for parsing AIX XCOFF object files header . to [XCOFF] Add functionality for parsing AIX XCOFF object files header . .Mar 15 2019, 9:27 AM
llvm/include/llvm/Object/XCOFFObjectFile.h
45

When _XCOFF_UOFFSET is set, the AIX headers treat this field as unsigned. Indications are that values greater than those of the corresponding signed type are indeed valid (despite difficulties in using files with such values with the AIX system linker).

llvm/lib/Object/XCOFFObjectFile.cpp
242

getObject below does size checking too. What does having this check here add?

I've added a few reviewers who have committed to the other file formats recently since none of us have a lot of experience with this part of llvm.

llvm/include/llvm/Object/XCOFFObjectFile.h
37

Rather then defining these in the llvm::object namespace why not drop the XCOFF part of the name and make the defintion nested inside XCOFFObjectFile?

54

The only use of this is in XCOFFObjectFile.cpp, it should be defined there instead of in the header.

rnk added a comment.Mar 19 2019, 10:08 AM

The skeleton of the dumper seems fine.

My main question would be, how is this going to fit into MC and the rest of LLVM? We support 4(?) object file formats there now (ELF, COFF (pretty much assumes Windows), wasm, and MachO), and MC is not designed to be very extensible. Will Triple::isOSBinFormatCOFF return true for XCOFF, or will it be distinct?

llvm/include/llvm/Object/XCOFFObjectFile.h
37

(Not to bikeshed too much...) Personally, I'd leave this as is. It's consistent with the other object formats. It's useful to be able to do using namespace llvm::object;, but you cannot shorten XCOFFObjectFile::Header without a typedef or type alias.

In D59419#1435075, @rnk wrote:

My main question would be, how is this going to fit into MC and the rest of LLVM? We support 4(?) object file formats there now (ELF, COFF (pretty much assumes Windows), wasm, and MachO), and MC is not designed to be very extensible. Will Triple::isOSBinFormatCOFF return true for XCOFF, or will it be distinct?

Our intention is for XCOFF to be a distinct object file format. We had a look at the Windows COFF format and it does share some similarities with XCOFF, but overall I think they are too different to try to reconcile into a single COFF object file format. Jason already landed a patch for adding Aix and XCOFF to the triple (here) and we treat XCOFF as a distinct object format there as well.

DiggerLin updated this revision to Diff 192269.Mar 26 2019, 7:08 AM
DiggerLin marked 5 inline comments as done.

changed the code based on the comment.

  1. changed the support::ubig32_t SymbolTableOffset;
  2. move the getObject function to llvm/lib/Object/XCOFFObjectFile.cpp
  3. deleted the checkSize function definition and removed the checkSize from XCOFFObjectFile::XCOFFObjectFile
llvm/include/llvm/Object/XCOFFObjectFile.h
37

I am agreed with Reid Kleckner.

45

changed to support::ubig32_t SymbolTableOffset

54

OK. I can move it to XCOFFObjectFile.cpp

llvm/lib/Object/XCOFFObjectFile.cpp
242

I have deleted the checkSize function definition and removed the check size here

DiggerLin updated this revision to Diff 192273.Mar 26 2019, 7:32 AM

changed the code based on the comment.

1.changed the support::ubig32_t SymbolTableOffset;
2.move the getObject function to llvm/lib/Object/XCOFFObjectFile.cpp
3.deleted the checkSize function definition and removed the checkSize from XCOFFObjectFile::XCOFFObjectFile

sfertile accepted this revision.Mar 29 2019, 6:46 AM
sfertile marked an inline comment as done.

Other the a few minor nit picks, this LGTM.

llvm/include/llvm/Object/XCOFFObjectFile.h
37

Fair enough.

108

minor nit: add a blank line before the endif

llvm/include/llvm/ObjectYAML/XCOFFYAML.h
12

blank line before the ifndef.

19

minor nit: no blank line between the 2 namespace openings.

49

blank again.

llvm/lib/ObjectYAML/XCOFFYAML.cpp
20

nit: remove white-space.

This revision is now accepted and ready to land.Mar 29 2019, 6:46 AM

LGTM with minor changes.

llvm/lib/Object/XCOFFObjectFile.cpp
121

Minor nit: Naming is not consistent (ret versus Result).

llvm/lib/ObjectYAML/XCOFFYAML.cpp
17

I am not seeing a need for <cstdint> or <vector>. At the same time, <string.h> should be added for ::memset.

DiggerLin updated this revision to Diff 193097.Apr 1 2019, 8:38 AM
DiggerLin marked 9 inline comments as done.
DiggerLin edited the summary of this revision. (Show Details)

April:

  1. added some blank line and deleted some blank line as suggest.
  2. deleted some header files #include "llvm/ObjectYAML/YAML.h"

#include "llvm/Support/YAMLTraits.h"
#include <cstdint>
from xcoffyaml.cpp

DiggerLin updated this revision to Diff 193098.Apr 1 2019, 8:43 AM
DiggerLin added inline comments.
llvm/include/llvm/Object/XCOFFObjectFile.h
108

done

llvm/include/llvm/ObjectYAML/XCOFFYAML.h
19

deleted , thanks

49

added a blank line , thanks

llvm/lib/ObjectYAML/XCOFFYAML.cpp
17

I deleted the
-#include "llvm/ObjectYAML/YAML.h"
-#include "llvm/Support/YAMLTraits.h"
-#include <cstdint>
-#include <vector>

20

done

DiggerLin marked 5 inline comments as done.Apr 2 2019, 10:08 AM
DiggerLin added inline comments.
llvm/include/llvm/ObjectYAML/XCOFFYAML.h
12

done,thanks

llvm/lib/Object/XCOFFObjectFile.cpp
121

change to Result

llvm/lib/ObjectYAML/XCOFFYAML.cpp
17

I think <string.h> is already be included in the headers files which be included in #include "llvm/ObjectYAML/XCOFFYAML.h" ,and I tried to use -E of g++ to preprocessor the file , I can find the string.h in the preprocessor file.

llvm/lib/ObjectYAML/XCOFFYAML.cpp
17

Firstly, is ::memset part of the abstract interface (as opposed to an implementation-related detail) of any of the headers included directly by this file? I believe the answer is "no". Secondly, is <string.h> actually included by any of the headers in the LLVM project that are transitively included from this file? Of the 51 headers, none of them include <string.h> (although some include <cstring>, which does not have to declare ::memset).

The 51 headers I checked are:
llvm/ObjectYAML/YAML.h llvm/ADT/ArrayRef.h llvm/ADT/DenseMapInfo.h llvm/ADT/Hashing.h llvm/ADT/None.h llvm/ADT/Optional.h llvm/ADT/PointerIntPair.h llvm/ADT/PointerUnion.h llvm/ADT/STLExtras.h llvm/ADT/SmallString.h llvm/ADT/SmallVector.h llvm/ADT/StringExtras.h llvm/ADT/StringMap.h llvm/ADT/StringRef.h llvm/ADT/StringSwitch.h llvm/ADT/Twine.h llvm/ADT/iterator.h llvm/ADT/iterator_range.h llvm/Config/abi-breaking.h llvm/Config/llvm-config.h llvm/Support/AlignOf.h llvm/Support/Allocator.h llvm/Support/CBindingWrapping.h llvm/Support/Casting.h llvm/Support/Chrono.h llvm/Support/Compiler.h llvm/Support/DataTypes.h llvm/Support/Debug.h llvm/Support/Endian.h llvm/Support/Error.h llvm/Support/ErrorHandling.h llvm/Support/ErrorOr.h llvm/Support/FileSystem.h llvm/Support/Format.h llvm/Support/FormatProviders.h llvm/Support/FormatVariadicDetails.h llvm/Support/Host.h llvm/Support/MD5.h llvm/Support/MathExtras.h llvm/Support/MemAlloc.h llvm/Support/MemoryBuffer.h llvm/Support/NativeFormatting.h llvm/Support/PointerLikeTypeTraits.h llvm/Support/Regex.h llvm/Support/SMLoc.h llvm/Support/SourceMgr.h llvm/Support/SwapByteOrder.h llvm/Support/YAMLParser.h llvm/Support/YAMLTraits.h llvm/Support/raw_ostream.h llvm/Support/type_traits.h

@DiggerLin; as discussed off-list, I'll commit this for you with the additional change to include <string.h>.

This revision was automatically updated to reflect the committed changes.
MaskRay added inline comments.
llvm/trunk/lib/Object/XCOFFObjectFile.cpp
40 ↗(On Diff #193639)

return; can be deleted

52 ↗(On Diff #193639)

If you write llvm_unreachable (__builtin_unreachable() or __assume(false)), an return statement can be omitted.