Fix diff.

Fix diff

• Merge branch 'master'

Looks good.

• make kvatop handle dpcpu/vnet addresses properly

In D21555#473306, @jhibbits wrote:

This is very specific to AIM64 HPT. Can you rename it to kvm_..._hpt.c, or something, and add another key to the header to probe against for the particular pmap implementation? I'll want to add Book-E support, as well as AIM Radix when we do finally get radix stabilized.

[PPC64] libkvm minidump refactoring

• Avoid unnecessary page table copy
• dump_pmap_init() is now implemented only in moea64

In D21551#475431, @jhibbits wrote:

Can you add a key/sentinel into the dump structure to say what pmap it's using? libkvm will need it for properly decoding addresses, and that differential will also need to be updated to use the key and select a backend.

• Add mmu_name field to minidump header
• Move dump_pmap_init() to moea64
• Refactor dump_pmap() to allow copy elision

LGTM.

• [PPC64] Handle relocated kernels properly
• Merge branch 'master' into luporl-crashdump-libkvm

• Added startkernel, endkernel to minidump header

• Separate elf_common.h change
• Change R_PPC64_IRELATIVE to R_PPC_IRELATIVE in code

• Address reviews' comments

• Address jhibbits comments and add missing UMA bits

I'm not that familiar with this code, but overall the change looks good and seem to preserve the behavior of previous version, except for the part in the following comment.

In D21297#463780, @imp wrote:

In D21297#463778, @luporl wrote:

In D21297#463774, @imp wrote:

In D21297#463764, @luporl wrote:

I agree with @jhibbits: cas.c shouldn't be built for powerpc32, only powerpc64, but the change is OK.
If we go this way, then it is better to remove the (incorrect) conditional compilation of cas.c.
Else, powerpc/ofw/Makefile should be fixed.
This is the relevant part of it:

.if ${MACHINE_ARCH} == "powerpc64"
SRCS+=          cas.c
CFLAGS+=        -DCAS
.endif

It seems this is wrong when cross building to powerpc.
Perhaps it could be changed to something like this:

.if (!defined(TARGET_ARCH) && ${MACHINE_ARCH} == "powerpc64") || "${TARGET_ARCH}" == "powerpc64"
SRCS+=          cas.c
CFLAGS+=        -DCAS
.endif

But I'm also fine with just removing the if block.

TARGET_ARCH isn't a thing you can test anywhere outside of Makefile.inc1, so this suggestion can't be right. In the cross build case, we always set MACHINE_ARCH correctly.

Ok, but then the following use case is not supported, right?

cd /usr/src/stand && make TARGET=powerpc TARGET_ARCH=powerpc

Because the following command outputs "powerpc64":

cd src/stand
make buildenv TARGET=....

is what you need to do to cross build.

cd /usr/src/stand && make TARGET=powerpc TARGET_ARCH=powerpc -V MACHINE_ARCH

But when first performing a buildenv, then MACHINE_ARCH is correctly set:

cd /usr/src && make TARGET=powerpc TARGET_ARCH=powerpc buildenv
cd stand && make -V MACHINE_ARCH

If this is the case, the Makefile is already correct and no issues should occur on 32-bit systems.
Then this change would not be necessary, although it doesn't hurt.

It wouldn't change anything since the -m32 needed to do the cross build on powerpc64 wouldn't be included, and the wrong architecture compiler would be used if you tried it on, say, x86. We never test for TARGET or TARGET_ARCH outside of the Makefile.inc1 at the top level (well, there is an exception for gdb and maybe gcc, but the TARGET variable there isn't the same one and pre-dates the system's use of Makefile and will go away soon anyway).

In D21297#463774, @imp wrote:

In D21297#463764, @luporl wrote:

I agree with @jhibbits: cas.c shouldn't be built for powerpc32, only powerpc64, but the change is OK.
If we go this way, then it is better to remove the (incorrect) conditional compilation of cas.c.
Else, powerpc/ofw/Makefile should be fixed.
This is the relevant part of it:

.if ${MACHINE_ARCH} == "powerpc64"
SRCS+=          cas.c
CFLAGS+=        -DCAS
.endif

It seems this is wrong when cross building to powerpc.
Perhaps it could be changed to something like this:

.if (!defined(TARGET_ARCH) && ${MACHINE_ARCH} == "powerpc64") || "${TARGET_ARCH}" == "powerpc64"
SRCS+=          cas.c
CFLAGS+=        -DCAS
.endif

But I'm also fine with just removing the if block.

TARGET_ARCH isn't a thing you can test anywhere outside of Makefile.inc1, so this suggestion can't be right. In the cross build case, we always set MACHINE_ARCH correctly.

Looks good to me.

I agree with @jhibbits: cas.c shouldn't be built for powerpc32, only powerpc64, but the change is OK.

@jhibbits, this last change addresses your last comment (moving VSX code to _vsx.S files) and also adds ifunc support.

[PPC64] Optimize bcopy/memcpy/memmove

Commandeering to address issues and use ifunc to decide whether VSX should be used.

• Use ifunc to choose best implementation based on running system

Taking over to add ifunc support, which will make it possible to have the optimized strcpy version and avoid breaking POWER5 and earlier.

In D21131#459452, @jhibbits wrote:

Looks good. Can the same change apply to powerpc?

• [PPC64] strncpy - fix rtld crash

• [PPC64] strncpy - fix rtld-libc build issue

In D20827#458843, @jhibbits wrote:

Thanks for checking. Looks good. I assume you tested on bare metal, too?

This last change fixes the previous "dst not always zeroed" issue and adds ifunc support to strncpy, so that the optimized version is selected on ISAs >= 2.05 while others can use the fallback implementation in C.

• [PPC64] strncpy - fix 'dst' not zeroed issue
• Initial ifunc capable strncpy implementation

• Add missing space

Redo merge:

In D21102#458426, @markj wrote:

In D21102#458391, @luporl wrote:

Now the merge result should match the behavior seen in upstream.
Was this what you had in mind? Or is the plan to revert the local changes and apply this patch on it instead?

I think we should indeed revert the local changes and apply the two patches from upstream, but IMO it's fine to do that in a single commit. I believe that is effectively what you have done here?

LGTM

Now the merge result should match the behavior seen in upstream.

• Match upstream behavior

I guess it is ok now.

• Fix merge issues

In D21102#458061, @markj wrote:

Were there any conflicts in the merge?

In D15369#456889, @jhibbits wrote:

Have you checked performance on this latest version?

• Addressed jhibbits' comments

• Fix cross build detection
• Refactored LIB32LD detection code
• Avoid using short form of -fuse-ld, that avoids issues with native builds and picking up a newer ld in PATH
• Using COMPILER_TYPE instead of LINKER_TYPE in stand/defs.mk, as an installed /usr/local/bin/ld pointing to ld.bfd can confuse LINKER_TYPE detection in this case.
• Aborting if LIB32LD is not defined when building stand. This will tipically happen when trying to build stand alone and without performing a 'make buildenv' first

I've tested @alfredo.junior_eldorado.org.br's patch and I've found a few issues, that I plan to fix in the next diff, as well as address @imp's comments.

I've posted a previous diff over an already patched file, that temporarily screwed the patch/history.

• [PPC64] Implement CAS
• Skip CAS if PSL_HV bit is set on MSR

• Fix inverted tab/newline in asm

Skip CAS if PSL_HV bit is set on MSR

LGTM.

I consider the strncpy implementation complete now.
Adding ifunc to select the optimized implementation, however, is still not possible, as rtld doesn't support it yet.

• Handled misalignment issues
• Improved implementation
• Now using memset() for faster zeroing of dst buffer

Looks good.
But I think MOEA64_STATS should become a kernel config option, to make it easier to enable the statistics and to have this option documented.

Nice catch!

Changed register convention.
Still need to investigate and fix the misaligned access issue.

• Use %r* instead of raw numbers for registers

• Addressed jhibbits' comments

• Address jhibbits comments