Fine with me.

Yes we should build only one or the other and _startup_libs reaching into gnu/lib/csu directly bypassed the ${MK_BSD_CRTBEGIN} test in gnu/lib/Makefile.

This does not matter for x86 at compile time, only at the link time

In D18369#392138, @imp wrote:

I looked at this on my phone a few days ago and meant to stamp it with LGTM when I got back to my computer, but that fell through the cracks.

rS341437

Also, formally architectures can have different -fPIC and -fPIE ABIs, so perhaps we really need libXXX_pie.a, and e.g. libc_pic.a and libc_pie.a simultaneously.

Smoke test in my staging tree (this patch plus 3 unrelated changes) looks good.

Presumably we should build INTERNALLIBs and PRIVATELIBs as both libfoo.a and libfoo_pic.a (or some similar scheme) and choose the appropriate one when linking the binary. I don't know how far down that path we want to go though.

I tested this patch in my tree, with BIND_NOW on by default, PIE on by default, and rS341429 reverted. Sanity tests on a few threaded applications showed no issues. Building vanilla FreeBSD + this patch for testing now.

IMO go ahead and commit

Will test shortly

In D18307 @kib suggests not installing as objdump; leave both reviews open until we decide.

Oh, maybe I'm conflating a different comment with something about mkfifo, but it was in D15968. In any case, the issue is that with cmd | while ... a return in the while loop returns from the subshell, not the function. There's a decent Stack Overflow discussion at https://stackoverflow.com/questions/13726764/while-loop-subshell-dilemma-in-bash

LGTM. One of either @kib or @markj suggested eliminating the mkfifo but I believe we cannot without a more capable shell.

Is it acceptable if some binaries fail?

In D18319#389890, @lattera-gmail.com wrote:

I don't know why you can't update this patch, as it's editable by all users.

In D18307#389445, @kib wrote:

What are the big non-implemented features ?

Combined with D18307 the only binutils tool installed on amd64, arm64, armv7 will be GNU as.

Plan to migrate to llvm-objdump instead, in D18307

In D18309#388676, @bcr wrote:

OK from manpages, others may have comments on the content itself.

Clean up mandoc -Tlint and/or igor complaints.

Split mach-o options to subsection.

See also D18307.

See also D13881 (deprecation notice for GNU objdump) and D7338 (old review to disconnect GNU objdump w/o replacement).

Adding @arichardson for comment on Linux bootstrapping.

Also depends on D18037

@arichardson I'm fine with this change in FreeBSD (if we end up with a different approach upstream we can just migrate to it on the next elftoolchain update).

I don't really like this, but given that any failure should be fairly straightforward to track down OK.

See also D7941

It looks like other existing files all use .align, I would probably keep that consistent.

I suspect only crtn.S (i.e., the _init and _fini epilogues need the 4-byte alignment treatment.

@oshogbo if you commit this to FreeBSD I'll grab the diff and commit to ELF Tool Chain.