[test] llvm-ar: Adjust 2 tests to pass again after inadvertent unXFAIL for some target triples

[AnthonyLatsis]

The problem with the current target={{.*}}-darwin{{.*}} XFAIL condition (changed in #130144) is that the Swift build script uses Apple platform names like 'macosx', not 'darwin', for the LLVM target triple, e.g. arm64-apple-macosx13.0.

These tests appear to have been originally XFAILed because the default format on macOS (darwin) adds newlines as padding to align members. See:

llvm-project/llvm/lib/Object/ArchiveWriter.cpp

Lines 897 to 904 in ee8394d

	// ld64 expects the members to be 8-byte aligned for 64-bit content and at
	// least 4-byte aligned for 32-bit content. Opt for the larger encoding
	// uniformly. This matches the behaviour with cctools and ensures that ld64
	// is happy with archives that we generate.
	unsigned MemberPadding =
	isDarwin(Kind) ? offsetToAlignment(Data.size(), Align(8)) : 0;
	unsigned TailPadding =
	offsetToAlignment(Data.size() + MemberPadding, Align(2));

Use --format=gnu to cope with the differences in the output and reenable the tests.

rdar://157213658

[llvmbot]

@llvm/pr-subscribers-llvm-binary-utilities

Author: Anthony Latsis (AnthonyLatsis)

Changes

The history of these XFAILs is clouded. Initially added as target-based checks in
629273e for somewhat vague reasons, soon after switched to host-based checks in 20b2cd3 "due to the problem being related to the darwin host and not the target", and recently reverted back to target-based in #130144 because, to my understanding, the tests can unexpectedly pass on arm64 macOS with llvm-ar cross-compiled to baremetal arm64.

Anyway, the problem with the current target={{.*}}-darwin{{.*}} is that the Swift build script uses Apple platform names like 'macosx', not 'darwin', for the LLVM host target triple.

---

Full diff: https://github.com/llvm/llvm-project/pull/159796.diff

2 Files Affected:

• (modified) llvm/test/tools/llvm-ar/extract.test (+1)
• (modified) llvm/test/tools/llvm-ar/print.test (+1)

diff --git a/llvm/test/tools/llvm-ar/extract.test b/llvm/test/tools/llvm-ar/extract.test
index bf46cc0743c7d..474dc8bb530ec 100644
--- a/llvm/test/tools/llvm-ar/extract.test
+++ b/llvm/test/tools/llvm-ar/extract.test
@@ -1,5 +1,6 @@
 ## Test extract operation.
 # XFAIL: target={{.*}}-darwin{{.*}}
+# XFAIL: target={{.*}}-apple{{.*}}
 
 # RUN: rm -rf %t && mkdir -p %t/extracted/
 
diff --git a/llvm/test/tools/llvm-ar/print.test b/llvm/test/tools/llvm-ar/print.test
index 997c05f225a8b..30169de9344fc 100644
--- a/llvm/test/tools/llvm-ar/print.test
+++ b/llvm/test/tools/llvm-ar/print.test
@@ -1,5 +1,6 @@
 ## Test Print output
 # XFAIL: target={{.*}}-darwin{{.*}}
+# XFAIL: target={{.*}}-apple{{.*}}
 
 # RUN: rm -rf %t && mkdir -p %t
 # RUN: echo file1 > %t/1.txt

[jh7370]

Could you merge in changes from main, please, so that the pre-commit CI runs against a (hopefully) working main?

[jh7370]

LGTM, but maybe an Apple developer would be better placed to confirm.

@alexander-shaposhnikov / @drodriguez / @RIscRIpt can any of you help?

[drodriguez]

The problem is that the tests are liberal in using --format=gnu and it seems that the default format in macOS is probably darwin which seems to add newlines at the end of the files (I don't know why).

I think adding a couple of --format=gnu when creating the archives fixes the tests and should allow them to run on macOS no matter if you are targetting macOS or other platform, and no matter the triple spelling being used.

[drodriguez]

I imagine the reason is

llvm-project/llvm/lib/Object/ArchiveWriter.cpp

Lines 897 to 904 in ee8394d

	// ld64 expects the members to be 8-byte aligned for 64-bit content and at
	// least 4-byte aligned for 32-bit content. Opt for the larger encoding
	// uniformly. This matches the behaviour with cctools and ensures that ld64
	// is happy with archives that we generate.
	unsigned MemberPadding =
	isDarwin(Kind) ? offsetToAlignment(Data.size(), Align(8)) : 0;
	unsigned TailPadding =
	offsetToAlignment(Data.size() + MemberPadding, Align(2));

To get the same behaviour with the default format in both gnu, bsd and darwin, you can use something like file001 instead of file1, which adds newline padding bytes until 8 byte boundaries.

I checked Xcode's ar and it doesn't actually add that padding, so not sure why it was needed ~10 years ago when those lines where added.

[AnthonyLatsis]

@drodriguez Thank you for helping out! I really appreciate the explanation.