In D32058#723540, @me_cameronkatri.com wrote:

readelf is just a symlink to readobj, so in order to have a full llvm binutils instead of elftoolchain with WITH_LLVM_BINUTILS we need llvm-readelf.

Hm, one thing is missing: why do we need this tool? :) Last time I looked it was a tool specifically for llvm's regression tests. Do we really want to build this unconditionally?

LGTM, thanks!

I did this slightly differently in https://github.com/DimitryAndric/freebsd-src/commit/73a8f96dc7c12ebf76f5a40a7f1208c11f75741f, and I put it in another if block. It would be nice to choose either my version or yours, and integrate it right away, so I don't get needless merge conflicts the next time I sync up the llvm-13-update branch with main.

Let's do this for now to get the PowerPC builds working again. But also be aware that the bisected upstream commit is only exposing an underlying issue: most likely the root cause is in the PowerPC backend.

In D31711#716449, @royger wrote:

In D31711#716440, @ehem_freebsd_m5p.com wrote:

No, then you would be doing arithmetic on a void pointer, which isn't officially legal (size of void being undefined). Better to do the math on integers and cast to the correct type.

It's a GNU C extension which I thought was fine to be used, as we already use other GNU C extensions I think.

Use conditional FreeBSD block, and our own __offsetof().

In D31711#715616, @royger wrote:

I think you can also remove the cast to vm_paddr_t while there, the field is declared as uint64_t.

In D31708#715404, @dim wrote:

Hmm the whole vflag handling seems to have been a no-op? I wonder when it disappeared, probably when a.out support was deleted from this code?

Hmm the whole vflag handling seems to have been a no-op? I wonder when it disappeared, probably when a.out support was deleted from this code?

I wouldn't say "reverts LLVM commit 2518433f861fcb877d0a7bdd9aec1aec1f77505a", but something like "amends LLVM commit 2518433f861fcb877d0a7bdd9aec1aec1f77505a", as we're adding code here. But otherwise, LGTM!

In D31603#712550, @dim wrote:

I know that when glibc changed something in this area they got complaints about programs breaking, if those should not have done the overlapping memcpy's.

Before this could be accepted I'd at least expect a full ports exp-run, and quite a bit of testing on the resulting packages, as changing the behavior of memcpy() as above will very likely lead to some failures. Strictly speaking you should never call memcpy() with overlapping arguments, but our traditional implementation has always allowed it. So how much fallout would this give? I know that when glibc changed something in this area they got complaints about programs breaking, if those should not have done the overlapping memcpy's.