Quoting Michael Ellerman <m...@ellerman.id.au>:

Christophe Leroy <christophe.le...@csgroup.eu> writes:
Le 03/11/2020 à 19:13, Christophe Leroy a écrit :
Le 23/10/2020 à 15:24, Michael Ellerman a écrit :
Christophe Leroy <christophe.le...@csgroup.eu> writes:
Le 24/09/2020 à 15:17, Christophe Leroy a écrit :
Le 17/09/2020 à 14:33, Michael Ellerman a écrit :
Christophe Leroy <christophe.le...@csgroup.eu> writes:

What is the status with the generic C vdso merge ?
In some mail, you mentionned having difficulties getting it working on
ppc64, any progress ? What's the problem ? Can I help ?

Yeah sorry I was hoping to get time to work on it but haven't been able
to.

It's causing crashes on ppc64 ie. big endian.
...

Can you tell what defconfig you are using ? I have been able to setup a full glibc PPC64 cross compilation chain and been able to test it under QEMU with success, using Nathan's vdsotest tool.

What config are you using ?

ppc64_defconfig + guest.config

Or pseries_defconfig.

I'm using Ubuntu GCC 9.3.0 mostly, but it happens with other toolchains too.

At a minimum we're seeing relocations in the output, which is a problem:

   $ readelf -r build\~/arch/powerpc/kernel/vdso64/vdso64.so
   Relocation section '.rela.dyn' at offset 0x12a8 contains 8 entries:
     Offset          Info           Type           Sym. Value    Sym. Name + Addend
   000000001368  000000000016 R_PPC64_RELATIVE                     7c0
   000000001370  000000000016 R_PPC64_RELATIVE                     9300
   000000001380  000000000016 R_PPC64_RELATIVE                     970
   000000001388  000000000016 R_PPC64_RELATIVE                     9300
   000000001398  000000000016 R_PPC64_RELATIVE                     a90
   0000000013a0  000000000016 R_PPC64_RELATIVE                     9300
   0000000013b0  000000000016 R_PPC64_RELATIVE                     b20
   0000000013b8  000000000016 R_PPC64_RELATIVE                     9300

Looks like it's due to the OPD and relation between the function() and .function()

By using DOTSYM() in the 'bl' call, that's directly the dot function which is called and the OPD is
not used anymore, it can get dropped.

Now I get .rela.dyn full of 0, don't know if we should drop it explicitely.

What is the status now with latest version of CVDSO ? I saw you had it in next-test for some time,
it is not there anymore today.

Still having some trouble with the compat VDSO.

eg:

$ ./vdsotest clock-gettime-monotonic verify
timestamp obtained from kernel predates timestamp
previously obtained from libc/vDSO:
        [1346, 821441653] (vDSO)
        [570, 769440040] (kernel)


And similar for all clocks except the coarse ones.


Ok, I managed to get the same with QEMU. Looking at the binary, I only see an mftb instead of the mftbu/mftb/mftbu triplet.

Fix below. Can you carry it, or do you prefer a full patch from me ? The easiest would be either to squash it into [v13,4/8] ("powerpc/time: Move timebase functions into new asm/timebase.h"), or to add it between patch 4 and 5 ?

diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index f877a576b338..c3473eb031a3 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -1419,7 +1419,7 @@ static inline void msr_check_and_clear(unsigned long bits)
                __msr_check_and_clear(bits);
 }

-#if defined(CONFIG_PPC_CELL) || defined(CONFIG_E500)
+#if defined(__powerpc64__) && (defined(CONFIG_PPC_CELL) || defined(CONFIG_E500))
 #define mftb()         ({unsigned long rval;                           \
                        asm volatile(                                   \
                                "90:       mfspr %0, %2;\n"           \
diff --git a/arch/powerpc/include/asm/timebase.h b/arch/powerpc/include/asm/timebase.h
index a8eae3adaa91..7b372976f5a5 100644
--- a/arch/powerpc/include/asm/timebase.h
+++ b/arch/powerpc/include/asm/timebase.h
@@ -21,7 +21,7 @@ static inline u64 get_tb(void)
 {
        unsigned int tbhi, tblo, tbhi2;

-       if (IS_ENABLED(CONFIG_PPC64))
+       if (IS_BUILTIN(__powerpc64__))
                return mftb();

        do {

Reply via email to