feat: add openharmony header

[richerfu]

This is a new PR #20020, which adds OpenHarmony header files for use with zig cc. Following the suggestions from PR #20020 and #21809, this PR only includes the logic for generating header files, while the remaining adaptation logic will be handled in other PRs.

cc @alexrp

Diff logic:

1. generate the full musl headers map and key is relative path:
   i. Put musl/include
   ii. Put musl/arch/generic
   iii. Put musl/arch/$arch
2. iterate the full musl headers map and check if the file exists in the search path:
   i. If the file exists, read the file and remove the comments and spaces and lines
   ii. Calculate the hash of the file content and check if the hash is the same
   iii. If the hash is the same, we can reduce the size
   iv. If the hash is different, we should save the content
3. Save the content to the out dir
   i. If the hit count is greater than 1, save the content to the generic-ohos dir
   ii. If the hit count is equal to 1, save the content to the target dir

[alexrp]

So the idea is to use the original musl headers for cases where they are semantically identical to the OpenHarmony ones anyway? Good idea, I like it.

A few thoughts:

• arm-linux-ohos should be arm-linux-ohoseabi (see std.Target: Introduce Abi.ohoseabi to distinguish the soft float case. #21605). This is a Zig-ism that helps us to know that Abi.ohoseabi is soft float (Abi.ohos would be ambiguous).
• It seems like all the header files added in this PR lost their trailing newline.
• I don't understand why e.g. aarch64-linux-ohos/bits/stat.h shows up in this PR, since it seems to be identical to generic-musl/bits/stat.h.
• I wonder if the process_headers_ohos.zig script could be merged with process_headers.zig now, with an --abi ohos flag? The latter script has been simplified quite a bit since your first PR (and will be simplified more in Add std.zig.target.glibcRuntimeTriple() and use it in std.Build.Step.Run and process_headers.zig #22090), so this might make sense to do.

[richerfu]

According to https://github.com/ziglang/zig/blob/master/src/musl.zig#L461 , it seems that when the musl is built, the original musl header file will be searched first.
Therefore, the new header file only provides the parts that are different from musl.

• arm-linux-ohoseabi There are no differences from the original musl's arm architecture, so no additional files will be generated
• aarch64-linux-ohos/bits/stat.h There is a very small difference.

  // aarch64-linux-ohos/bits/stat.h
  struct stat {
   dev_t st_dev;
   ino_t st_ino;
   mode_t st_mode;
   nlink_t st_nlink;
   uid_t st_uid;
   gid_t st_gid;
   dev_t st_rdev;
   unsigned long __pad;
   off_t st_size;
   blksize_t st_blksize;
   int __pad2;
   blkcnt_t st_blocks;
   struct timespec st_atim;
   struct timespec st_mtim;
   struct timespec st_ctim;
       // the musl's origin code is unsigned __unused[2] and ohos's file one char is more.
   unsigned __unused1[2];
  }; 

• process_headers_ohos.zig script could be merged with process_headers.zig now
  I think merging is not very good, because in the process of comparing the differences between ohos header files, a lot of processing is not needed by the original script, and we rely on the musl header files that have been processed by the original script. Independent scripts help us maintain musl and ohos versions of musl more conveniently, and their code will look much simpler.

[alexrp]

According to https://github.com/ziglang/zig/blob/master/src/musl.zig#L461 , it seems that when the musl is built, the original musl header file will be searched first.
Therefore, the new header file only provides the parts that are different from musl.

Note that this code is for building static musl artifacts. Since, as we discussed previously, we will only support dynamic linking for OpenHarmony, this code only matters for building crti.o/crtn.o and crt1.o/scrt1.o.

For the include paths that are exposed to user code, see:

zig/lib/std/zig/LibCDirs.zig

Lines 169 to 214 in aa7d138

	const generic_name = libCGenericName(target);
	// Some architecture families are handled by the same set of headers.
	const arch_name = if (target.abi.isMusl())
	std.zig.target.muslArchNameHeaders(target.cpu.arch)
	else
	@tagName(target.cpu.arch);
	const os_name = @tagName(target.os.tag);
	const abi_name = if (target.abi.isMusl())
	std.zig.target.muslAbiNameHeaders(target.abi)
	else
	@tagName(target.abi);
	const arch_include_dir = try std.fmt.allocPrint(
	arena,
	"{s}" ++ s ++ "libc" ++ s ++ "include" ++ s ++ "{s}-{s}-{s}",
	.{ zig_lib_dir, arch_name, os_name, abi_name },
	);
	const generic_include_dir = try std.fmt.allocPrint(
	arena,
	"{s}" ++ s ++ "libc" ++ s ++ "include" ++ s ++ "generic-{s}",
	.{ zig_lib_dir, generic_name },
	);
	const generic_arch_name = target.osArchName();
	const arch_os_include_dir = try std.fmt.allocPrint(
	arena,
	"{s}" ++ s ++ "libc" ++ s ++ "include" ++ s ++ "{s}-{s}-any",
	.{ zig_lib_dir, generic_arch_name, os_name },
	);
	const generic_os_include_dir = try std.fmt.allocPrint(
	arena,
	"{s}" ++ s ++ "libc" ++ s ++ "include" ++ s ++ "any-{s}-any",
	.{ zig_lib_dir, os_name },
	);
	const list = try arena.alloc([]const u8, 4);
	list[0] = arch_include_dir;
	list[1] = generic_include_dir;
	list[2] = arch_os_include_dir;
	list[3] = generic_os_include_dir;
	return .{
	.libc_include_dir_list = list,
	.libc_installation = null,
	.libc_framework_dir_list = &.{},
	.sysroot = null,
	.darwin_sdk_layout = .vendored,
	};

In both code paths, we will need to check for target.abi.isOpenHarmony() and add the OpenHarmony paths before the regular musl paths so that the headers that are different will be picked up as expected.

aarch64-linux-ohos/bits/stat.h There is a very small difference.

Ah, ok. That's pretty silly, but not easy to fix without hacky special cases in the script.

[alexrp]

I think merging is not very good, because in the process of comparing the differences between ohos header files, a lot of processing is not needed by the original script, and we rely on the musl header files that have been processed by the original script. Independent scripts help us maintain musl and ohos versions of musl more conveniently, and their code will look much simpler.

In any case, I suggest getting rid of all that MultiArch/MultiAbi complexity. I removed that from process_headers.zig here: https://github.com/ziglang/zig/pull/21717/files#diff-ac8b4b89c2c051974a6382b5268835c94ce84ce19e955ff2568c79fbcfd8e0c0

[richerfu]

I think merging is not very good, because in the process of comparing the differences between ohos header files, a lot of processing is not needed by the original script, and we rely on the musl header files that have been processed by the original script. Independent scripts help us maintain musl and ohos versions of musl more conveniently, and their code will look much simpler.

In any case, I suggest getting rid of all that MultiArch/MultiAbi complexity. I removed that from process_headers.zig here: https://github.com/ziglang/zig/pull/21717/files#diff-ac8b4b89c2c051974a6382b5268835c94ce84ce19e955ff2568c79fbcfd8e0c0

Removed.

[richerfu]

That's pretty silly, but not easy to fix without hacky special cases in the script.

I'm not sure if changing the field name will have any impact on the system or code. So I'm going to keep the difference.