dl_iterate_phdr implementation

[LemonBoy]

Also comes with a libc-less version that should work just fine in most cases.
I guess the code is portable enough to work on *BSDs too, I'd be happy to move it out of the linux namespace if somebody tests it.

I didn't manage to mark the __ehdr_entry as weak, similar to how you'd do with this C declaration:

extern const char __ehdr_start __attribute__((weak));

I'll squash the spurious commit once the review is over.

[andrewrk]

This looks good. I'm taking a look into the extern weak thing and see if I can resolve that, then I'll merge.

[andrewrk]

Ah - I do think it would be valuable to get some test coverage for this. Related:

zig/test/build_examples.zig

Lines 20 to 26 in 75d42ac

	if (false) {
	// TODO this test is disabled because it is failing on the CI server's linux. when this is fixed
	// enable it for at least linux
	// TODO hook up the DynLib API for windows using LoadLibraryA
	// TODO figure out how to make this work on darwin - probably libSystem has dlopen/dlsym in it
	cases.addBuildFile("test/standalone/load_dynamic_library/build.zig");
	}

[andrewrk]

Some fix ups for you to look at, and then I do think we should have tests for this, and then I think it will be good to merge.

[daurnimator]

Could just be orelse unreachable I think?

[LemonBoy]

Good catch, I went with .?

[LemonBoy]

Is this PR ok to merge even before we solve the weak thing? What are the implications of this?

It should not matter since lld produces that symbol (and so does binutils as).

I've added a simple test for the non-libc case that should be quite exhaustive.

A few notes:

• Is the exposed API ergonomic enough? I've made it accept a comptime T: type parameter in order to make it more type-safe but that's it.
• We require the callback to be extern because we may call the libc function (IMO that's not needed, this implementation is 100% compatible with either libc and, if I didn't overlook anything, also with BSDs). This means the callback is effectively exported even though that's not needed, all we care for is the calling convention. Until use a builtin enum for calling conventions instead of keywords #661 (and unless @export is extended to also allow the user to select the symbol visibility) there's no way around this.

[daurnimator]

Is this liable to break in future if we somehow end up using other libraries in the test suite?

[LemonBoy]

Yep, but the test is easy to change when/if that happens.

[andrewrk]

Test failure on the CI:

848/1106 os.linux.test.test "std-linux-x86_64-Debug-c-multi dl_iterate_phdr"...test failure
/home/vsts/work/1/s/std/testing.zig:146:14: 0x2ad418 in testing.expect (test)
/home/vsts/work/1/s/std/os/linux/test.zig:80:11: 0x3085a2 in os.linux.test.test "std-linux-x86_64-Debug-c-multi dl_iterate_phdr" (test)
/home/vsts/work/1/s/std/special/test_runner.zig:13:25: 0x6e8cca in std.special.main (test)
/home/vsts/work/1/s/std/special/bootstrap.zig:126:22: 0x6e8996 in std.special.main (test)

[LemonBoy]

Test failure on the CI:

@daurnimator was right, the test was too flakey. I've replaced it with one inspired by this one and now the CI is green :)