Re: [PATCH] powerpc: allow cross-compilation of ppc64 kernel

[Segher Boessenkool]

On Fri, Nov 06, 2015 at 03:09:40PM -0600, Scott Wood wrote:
> Why is GCC building ppc64 object files but telling the linker --oformat elf32-
> powerpcle?  Are different options somehow being passed to GCC in one case 
> versus the other?

This was changed for GCC 6 in , could one of
you check if that fixes this problem?  If so we'll need to backport it.


Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc: allow cross-compilation of ppc64 kernel

[Scott Wood]

On Fri, 2015-11-06 at 23:22 +0100, Laurent Vivier wrote:
> Le 06/11/2015 22:09, Scott Wood a écrit :
> > On Thu, 2015-11-05 at 12:47 +0100, Laurent Vivier wrote:
> > > When I try to cross compile a ppc64 kernel, it generally
> > > fails on the VDSO stage. This is true for powerpc64 cross-
> > > compiler, but also when I try to build a ppc64le kernel
> > > on a ppc64 host.
> > > 
> > > VDSO64L fails:
> > > 
> > >   VDSO64L arch/powerpc/kernel/vdso64/vdso64.so.dbg
> > > /usr/bin/powerpc64-linux-gnu-ld: arch/powerpc/kernel/vdso64/sigtramp.o:
> > > file class ELFCLASS64 incompatible with ELFCLASS32
> > > /usr/bin/powerpc64-linux-gnu-ld: final link failed: File in wrong format
> > > 
> > > This fails because gcc calls "collect2" with
> > > "--oformat elf32-powerpcle" with ppc64 objects, without the
> > > "--oformat" ld works well because it use the format of the
> > > first object as output format.
> > > 
> > > As this case is correctly managed to build the other kernel
> > > objects, this patch replaces $(GCC) by $(LD) to generate the
> > > VDSO objects.
> > 
> > I cross-compile ppc64 kernels and have not seen this problem.  I do need 
> > to 
> > pass in -m64 as part of $(CC) if it's not the toolchain default, which is 
> > not 
> > nice, but the proper fix for that is to add -m64 in the makefiles -- and 
> > if I 
> > don't it fails way before VDSO.
> > 
> > Why is GCC building ppc64 object files but telling the linker --oformat 
> > elf32-
> > powerpcle?  Are different options somehow being passed to GCC in one case 
> > versus the other?
> 
> In fact, for all the other parts of the kernel, gcc is called with
> "-mlittle-endian -m64", ld with "-EL -m elf64lppc", and thus generates
> the good objects and calls ld with the good options ("elf64lppc"). I
> think gcc is never used to link, only to compile.
> This, I think, comes from:
> 
> arch/powerpc/Makefile:
> 
> ifeq ($(CONFIG_CPU_LITTLE_ENDIAN),y)
> override CC += -mlittle-endian
> override LD += -EL
> ...
> ifeq ($(HAS_BIARCH),y)
> override CC += -m$(CONFIG_WORD_SIZE)
> override LD += -m elf$(CONFIG_WORD_SIZE)$(LDEMULATION)

OK, that works if I completely remove the CC environment setting rather than 
just remove the -m64 from it.  It looks like that's been there longer than 
I've been building 64-bit kernels, so I wonder what originally prompted me to 
add the environment setting.

Yes, the kernel itself is linked with ld rather than gcc, but that's unusual. 
 There's nothing wrong with using gcc to link.

> So at this point, I can:
> 
> 1- either fix my compiler,
> 2- or fix the vdso64 linker command.

Do #1, as that's where the bug is, and if you work around it you'll have the 
same problem building other projects if they happen to specify the endianness 
explicitly.

-Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc: allow cross-compilation of ppc64 kernel

[Segher Boessenkool]

On Fri, Nov 06, 2015 at 04:55:49PM -0600, Segher Boessenkool wrote:
> On Fri, Nov 06, 2015 at 03:09:40PM -0600, Scott Wood wrote:
> > Why is GCC building ppc64 object files but telling the linker --oformat 
> > elf32-
> > powerpcle?  Are different options somehow being passed to GCC in one case 
> > versus the other?
> 
> This was changed for GCC 6 in , could one of
> you check if that fixes this problem?  If so we'll need to backport it.

Actually it already has been backported, r228089.


Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc: allow cross-compilation of ppc64 kernel

[Benjamin Herrenschmidt]

On Fri, 2015-11-06 at 15:09 -0600, Scott Wood wrote:
> On Thu, 2015-11-05 at 12:47 +0100, Laurent Vivier wrote:
> > When I try to cross compile a ppc64 kernel, it generally
> > fails on the VDSO stage. This is true for powerpc64 cross-
> > compiler, but also when I try to build a ppc64le kernel
> > on a ppc64 host.
> > 
> > VDSO64L fails:
> > 
> >   VDSO64L arch/powerpc/kernel/vdso64/vdso64.so.dbg
> > /usr/bin/powerpc64-linux-gnu-ld:
> > arch/powerpc/kernel/vdso64/sigtramp.o:
> > file class ELFCLASS64 incompatible with ELFCLASS32
> > /usr/bin/powerpc64-linux-gnu-ld: final link failed: File in wrong
> > format
> > 
> > This fails because gcc calls "collect2" with
> > "--oformat elf32-powerpcle" with ppc64 objects, without the
> > "--oformat" ld works well because it use the format of the
> > first object as output format.
> > 
> > As this case is correctly managed to build the other kernel
> > objects, this patch replaces $(GCC) by $(LD) to generate the
> > VDSO objects.

This is LE ? I think that's a bug in binutils or gcc ... I remember we
fought that a while ago for the openpower builds. It might have been
fixed in upstream toolchain.

Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH 0/3]perf/core: extend perf_reg and perf_sample_regs_intr

[Madhavan Srinivasan]

On Friday 06 November 2015 03:34 PM, Michael Ellerman wrote:
> On Fri, 2015-11-06 at 10:24 +0100, Peter Zijlstra wrote:
>> On Fri, Nov 06, 2015 at 12:57:17PM +0530, Madhavan Srinivasan wrote:
>>> On Thursday 05 November 2015 06:37 PM, Peter Zijlstra wrote:
 On Thu, Nov 05, 2015 at 02:16:15AM +0530, Madhavan Srinivasan wrote:
> Second patch updates struct arch_misc_reg for arch/powerpc with pmu 
> registers
> and adds offsetof macro for the same. It extends perf_reg_value()
> to use reg idx to decide on struct to return value from.
 Why; what's in those regs?
>>> Was out and did not have access to mail, so missed to respond in time.
>>>
>>> In current implementation of patch 2, have added 
>>> few pmu control/status and counter registers,
>>> which give additional information about the PMU context
>>> for the sample.
>> Yes, I saw that, you still haven't answered the question though. What is
>> in those regs? Why is exposing that information like this the best
>> option.
> It's a perrenial request from our hardware PMU folks to be able to see the raw
> values of the PMU registers.
>
> I think partly it's so that they can verify that perf is doing what they want,
> and some of it is that they're interested in some of the more obscure info 
> that
> isn't plumbed out through other perf interfaces.
>
> We've used various internal hacks over the years to keep them happy. This is 
> an
> attempt to use a somewhat standard mechanism.
>
> It would also be helpful for those of us working on the perf hardware 
> backends,
> to be able to verify that we're programming things correctly, without 
> resorting
> to debug printks etc.
>
> Basically we want to sample regs at the time of the perf interrupt, so we
> though PERF_SAMPLE_REGS_INTR made senes :)
>
> But if you think this is the wrong mechanism within perf, then please let us
> know.
>
> I know perf's mission is to abstract as much of the arcane hardware details
> into a generic interface and make PMUs actually useful for normal folks, and 
> we
> are committed to that, but it would also be useful to be able to get the raw
> values for a different type of user.
>
> Maddy's patch only exports PMC1-6 and MMCR0/1. I think we also need to export
> some others, in particular MMCRA has a lot of stuff in it, half of which is 
> not
> even architected. So that would have to be exported as "POWER8_MMCRA". And 
> then
> there's the SIAR/SDAR/SIER which contain a bunch of info on sampled
> instructions that is not currently plumbed out.

Sure. I will rework the patch to include the other regs also.

Maddy

>
> cheers
>

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH 0/3]perf/core: extend perf_reg and perf_sample_regs_intr

[Madhavan Srinivasan]

On Friday 06 November 2015 03:55 PM, Peter Zijlstra wrote:
> On Fri, Nov 06, 2015 at 09:04:00PM +1100, Michael Ellerman wrote:
>> It's a perrenial request from our hardware PMU folks to be able to see the 
>> raw
>> values of the PMU registers.
>>
>> I think partly it's so that they can verify that perf is doing what they 
>> want,
>> and some of it is that they're interested in some of the more obscure info 
>> that
>> isn't plumbed out through other perf interfaces.
>>
>> We've used various internal hacks over the years to keep them happy. This is 
>> an
>> attempt to use a somewhat standard mechanism.
>>
>> It would also be helpful for those of us working on the perf hardware 
>> backends,
>> to be able to verify that we're programming things correctly, without 
>> resorting
>> to debug printks etc.
>>
>> Basically we want to sample regs at the time of the perf interrupt, so we
>> though PERF_SAMPLE_REGS_INTR made senes :)
>>
>> But if you think this is the wrong mechanism within perf, then please let us
>> know.
>>
>> I know perf's mission is to abstract as much of the arcane hardware details
>> into a generic interface and make PMUs actually useful for normal folks, and 
>> we
>> are committed to that, but it would also be useful to be able to get the raw
>> values for a different type of user.
>>
>> Maddy's patch only exports PMC1-6 and MMCR0/1. I think we also need to export
>> some others, in particular MMCRA has a lot of stuff in it, half of which is 
>> not
>> even architected. So that would have to be exported as "POWER8_MMCRA". And 
>> then
>> there's the SIAR/SDAR/SIER which contain a bunch of info on sampled
>> instructions that is not currently plumbed out.
> OK, no objections then. But this is useful information and should be
> included in the patch set.
>

Sure. Will add the information in the next version.

Maddy


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH 0/3]perf/core: extend perf_reg and perf_sample_regs_intr

[Michael Ellerman]

On Fri, 2015-11-06 at 10:24 +0100, Peter Zijlstra wrote:
> On Fri, Nov 06, 2015 at 12:57:17PM +0530, Madhavan Srinivasan wrote:
> > On Thursday 05 November 2015 06:37 PM, Peter Zijlstra wrote:
> > > On Thu, Nov 05, 2015 at 02:16:15AM +0530, Madhavan Srinivasan wrote:
> > > > Second patch updates struct arch_misc_reg for arch/powerpc with pmu 
> > > > registers
> > > > and adds offsetof macro for the same. It extends perf_reg_value()
> > > > to use reg idx to decide on struct to return value from.
> > > Why; what's in those regs?
> > 
> > Was out and did not have access to mail, so missed to respond in time.
> > 
> > In current implementation of patch 2, have added 
> > few pmu control/status and counter registers,
> > which give additional information about the PMU context
> > for the sample.
> 
> Yes, I saw that, you still haven't answered the question though. What is
> in those regs? Why is exposing that information like this the best
> option.

It's a perrenial request from our hardware PMU folks to be able to see the raw
values of the PMU registers.

I think partly it's so that they can verify that perf is doing what they want,
and some of it is that they're interested in some of the more obscure info that
isn't plumbed out through other perf interfaces.

We've used various internal hacks over the years to keep them happy. This is an
attempt to use a somewhat standard mechanism.

It would also be helpful for those of us working on the perf hardware backends,
to be able to verify that we're programming things correctly, without resorting
to debug printks etc.

Basically we want to sample regs at the time of the perf interrupt, so we
though PERF_SAMPLE_REGS_INTR made senes :)

But if you think this is the wrong mechanism within perf, then please let us
know.

I know perf's mission is to abstract as much of the arcane hardware details
into a generic interface and make PMUs actually useful for normal folks, and we
are committed to that, but it would also be useful to be able to get the raw
values for a different type of user.

Maddy's patch only exports PMC1-6 and MMCR0/1. I think we also need to export
some others, in particular MMCRA has a lot of stuff in it, half of which is not
even architected. So that would have to be exported as "POWER8_MMCRA". And then
there's the SIAR/SDAR/SIER which contain a bunch of info on sampled
instructions that is not currently plumbed out.

cheers

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] cxl: Delete an unnecessary check before the function call "kfree"

[SF Markus Elfring]

From: Markus Elfring 
Date: Fri, 6 Nov 2015 11:00:23 +0100

The kfree() function tests whether its argument is NULL and then
returns immediately. Thus the test around the call is not needed.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/misc/cxl/context.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/misc/cxl/context.c b/drivers/misc/cxl/context.c
index 2faa127..52e39b6 100644
--- a/drivers/misc/cxl/context.c
+++ b/drivers/misc/cxl/context.c
@@ -275,9 +275,7 @@ static void reclaim_ctx(struct rcu_head *rcu)
if (ctx->kernelapi)
kfree(ctx->mapping);
 
-   if (ctx->irq_bitmap)
-   kfree(ctx->irq_bitmap);
-
+   kfree(ctx->irq_bitmap);
kfree(ctx);
 }
 
-- 
2.6.2

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH 0/3]perf/core: extend perf_reg and perf_sample_regs_intr

[Peter Zijlstra]

On Fri, Nov 06, 2015 at 09:04:00PM +1100, Michael Ellerman wrote:
> It's a perrenial request from our hardware PMU folks to be able to see the raw
> values of the PMU registers.
> 
> I think partly it's so that they can verify that perf is doing what they want,
> and some of it is that they're interested in some of the more obscure info 
> that
> isn't plumbed out through other perf interfaces.
> 
> We've used various internal hacks over the years to keep them happy. This is 
> an
> attempt to use a somewhat standard mechanism.
> 
> It would also be helpful for those of us working on the perf hardware 
> backends,
> to be able to verify that we're programming things correctly, without 
> resorting
> to debug printks etc.
> 
> Basically we want to sample regs at the time of the perf interrupt, so we
> though PERF_SAMPLE_REGS_INTR made senes :)
> 
> But if you think this is the wrong mechanism within perf, then please let us
> know.
> 
> I know perf's mission is to abstract as much of the arcane hardware details
> into a generic interface and make PMUs actually useful for normal folks, and 
> we
> are committed to that, but it would also be useful to be able to get the raw
> values for a different type of user.
> 
> Maddy's patch only exports PMC1-6 and MMCR0/1. I think we also need to export
> some others, in particular MMCRA has a lot of stuff in it, half of which is 
> not
> even architected. So that would have to be exported as "POWER8_MMCRA". And 
> then
> there's the SIAR/SDAR/SIER which contain a bunch of info on sampled
> instructions that is not currently plumbed out.

OK, no objections then. But this is useful information and should be
included in the patch set.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH 0/3]perf/core: extend perf_reg and perf_sample_regs_intr

[Michael Ellerman]

On Fri, 2015-11-06 at 13:17 +0530, Madhavan Srinivasan wrote:
> On Friday 06 November 2015 08:28 AM, Sukadev Bhattiprolu wrote:
> > Peter Zijlstra [pet...@infradead.org] wrote:
> > > On Thu, Nov 05, 2015 at 02:16:15AM +0530, Madhavan Srinivasan wrote:
> > > > Second patch updates struct arch_misc_reg for arch/powerpc with pmu 
> > > > registers
> > > > and adds offsetof macro for the same. It extends perf_reg_value()
> > > > to use reg idx to decide on struct to return value from.
> > > 
> > > Why; what's in those regs?
> > 
> > Those are PMU control registers/counters (in Patch 2) that are of
> > interest only in the context of a PMU interrupt and not relevant
> > to ptrace itself.
> 
> Yes. Thats right.

> > Could we add those registers to 'struct pt_regs' anyway?
> 
> I would prefer not to. Since as you mentioned, these are
> not relevant to ptrace. Currently patch 2, adds only few
> pmu registers, but would like to include more.

You can't just add them to pt_regs, it's part of the userspace ABI.

We could define a kernel internal version of pt_regs, but I don't think we want
to for this.

If we did that would bloat pt_regs for all users in the kernel, when we really
only want these regs for perf.

cheers

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH 0/3]perf/core: extend perf_reg and perf_sample_regs_intr

[Peter Zijlstra]

On Fri, Nov 06, 2015 at 12:57:17PM +0530, Madhavan Srinivasan wrote:
> 
> 
> On Thursday 05 November 2015 06:37 PM, Peter Zijlstra wrote:
> > On Thu, Nov 05, 2015 at 02:16:15AM +0530, Madhavan Srinivasan wrote:
> >> Second patch updates struct arch_misc_reg for arch/powerpc with pmu 
> >> registers
> >> and adds offsetof macro for the same. It extends perf_reg_value()
> >> to use reg idx to decide on struct to return value from.
> > Why; what's in those regs?
> 
> Was out and did not have access to mail, so missed to respond in time.
> 
> In current implementation of patch 2, have added 
> few pmu control/status and counter registers,
> which give additional information about the PMU context
> for the sample.

Yes, I saw that, you still haven't answered the question though. What is
in those regs? Why is exposing that information like this the best
option.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] uapi elf: delete unused macros

[mudongliang]

From 13f516acc709d88d3162e92bc891c8e39cc9fc1a Mon Sep 17 00:00:00 2001
From: mudongliang 
Date: Fri, 6 Nov 2015 14:35:19 +0800
Subject: [PATCH] unify the comment form and delete unused macros

Signed-off-by: mudongliang 
---
 arch/powerpc/boot/elf.h  | 6 ++
 include/uapi/linux/elf.h | 6 ++
 2 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/arch/powerpc/boot/elf.h b/arch/powerpc/boot/elf.h
index 1941bc5..e6e00ed 100644
--- a/arch/powerpc/boot/elf.h
+++ b/arch/powerpc/boot/elf.h
@@ -133,15 +133,13 @@ typedef struct elf64_phdr {
 #defineELFCLASSNONE0   /* EI_CLASS */
 #defineELFCLASS32  1
 #defineELFCLASS64  2
-#defineELFCLASSNUM 3
 
-#define ELFDATANONE0   /* e_ident[EI_DATA] */
+#define ELFDATANONE0   /* EI_DATA */
 #define ELFDATA2LSB1
 #define ELFDATA2MSB2
 
-#define EV_NONE0   /* e_version, EI_VERSION */
+#define EV_NONE0   /* EI_VERSION */
 #define EV_CURRENT 1
-#define EV_NUM 2
 
 #define ELFOSABI_NONE  0
 #define ELFOSABI_LINUX 3
diff --git a/include/uapi/linux/elf.h b/include/uapi/linux/elf.h
index 71e1d0e..ff81b20 100644
--- a/include/uapi/linux/elf.h
+++ b/include/uapi/linux/elf.h
@@ -342,15 +342,13 @@ typedef struct elf64_shdr {
 #defineELFCLASSNONE0   /* EI_CLASS */
 #defineELFCLASS32  1
 #defineELFCLASS64  2
-#defineELFCLASSNUM 3
 
-#define ELFDATANONE0   /* e_ident[EI_DATA] */
+#define ELFDATANONE0   /* EI_DATA */
 #define ELFDATA2LSB1
 #define ELFDATA2MSB2
 
-#define EV_NONE0   /* e_version, EI_VERSION */
+#define EV_NONE0   /* EI_VERSION */
 #define EV_CURRENT 1
-#define EV_NUM 2
 
 #define ELFOSABI_NONE  0
 #define ELFOSABI_LINUX 3
-- 
2.1.4


-- 
My best regards to you.

 No System Is Safe!
 mudongliang
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 1/1 v4] drivers/nvme: default to 4k device page size

[Nishanth Aravamudan]

On 05.11.2015 [11:58:39 -0800], Christoph Hellwig wrote:
> Looks fine,
> 
> Reviewed-by: Christoph Hellwig 
> 
> ... but I doubt we'll ever bother updating it.  Most architectures
> with arger page sizes also have iommus and would need different settings
> for different iommus vs direct mapping for very little gain.  There's a
> reason why we never bothered for RDMA either.

FWIW, whose tree should this go through? The bug only appears on Power,
afaik, but the patch is now just an NVMe change.

Thanks,
Nish

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc: allow cross-compilation of ppc64 kernel

[Scott Wood]

On Thu, 2015-11-05 at 12:47 +0100, Laurent Vivier wrote:
> When I try to cross compile a ppc64 kernel, it generally
> fails on the VDSO stage. This is true for powerpc64 cross-
> compiler, but also when I try to build a ppc64le kernel
> on a ppc64 host.
> 
> VDSO64L fails:
> 
>   VDSO64L arch/powerpc/kernel/vdso64/vdso64.so.dbg
> /usr/bin/powerpc64-linux-gnu-ld: arch/powerpc/kernel/vdso64/sigtramp.o:
> file class ELFCLASS64 incompatible with ELFCLASS32
> /usr/bin/powerpc64-linux-gnu-ld: final link failed: File in wrong format
> 
> This fails because gcc calls "collect2" with
> "--oformat elf32-powerpcle" with ppc64 objects, without the
> "--oformat" ld works well because it use the format of the
> first object as output format.
> 
> As this case is correctly managed to build the other kernel
> objects, this patch replaces $(GCC) by $(LD) to generate the
> VDSO objects.

I cross-compile ppc64 kernels and have not seen this problem.  I do need to 
pass in -m64 as part of $(CC) if it's not the toolchain default, which is not 
nice, but the proper fix for that is to add -m64 in the makefiles -- and if I 
don't it fails way before VDSO.

Why is GCC building ppc64 object files but telling the linker --oformat elf32-
powerpcle?  Are different options somehow being passed to GCC in one case 
versus the other?

-Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] powerpc/module: avoid memmove() in dedotify()

[Hombourger, Cedric]

0001-powerpc-module-avoid-memmove-in-dedotify.patch
Description: 0001-powerpc-module-avoid-memmove-in-dedotify.patch
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc: allow cross-compilation of ppc64 kernel

[Laurent Vivier]

Le 06/11/2015 22:09, Scott Wood a écrit :
> On Thu, 2015-11-05 at 12:47 +0100, Laurent Vivier wrote:
>> When I try to cross compile a ppc64 kernel, it generally
>> fails on the VDSO stage. This is true for powerpc64 cross-
>> compiler, but also when I try to build a ppc64le kernel
>> on a ppc64 host.
>>
>> VDSO64L fails:
>>
>>   VDSO64L arch/powerpc/kernel/vdso64/vdso64.so.dbg
>> /usr/bin/powerpc64-linux-gnu-ld: arch/powerpc/kernel/vdso64/sigtramp.o:
>> file class ELFCLASS64 incompatible with ELFCLASS32
>> /usr/bin/powerpc64-linux-gnu-ld: final link failed: File in wrong format
>>
>> This fails because gcc calls "collect2" with
>> "--oformat elf32-powerpcle" with ppc64 objects, without the
>> "--oformat" ld works well because it use the format of the
>> first object as output format.
>>
>> As this case is correctly managed to build the other kernel
>> objects, this patch replaces $(GCC) by $(LD) to generate the
>> VDSO objects.
> 
> I cross-compile ppc64 kernels and have not seen this problem.  I do need to 
> pass in -m64 as part of $(CC) if it's not the toolchain default, which is not 
> nice, but the proper fix for that is to add -m64 in the makefiles -- and if I 
> don't it fails way before VDSO.
> 
> Why is GCC building ppc64 object files but telling the linker --oformat elf32-
> powerpcle?  Are different options somehow being passed to GCC in one case 
> versus the other?

In fact, for all the other parts of the kernel, gcc is called with
"-mlittle-endian -m64", ld with "-EL -m elf64lppc", and thus generates
the good objects and calls ld with the good options ("elf64lppc"). I
think gcc is never used to link, only to compile.
This, I think, comes from:

arch/powerpc/Makefile:

ifeq ($(CONFIG_CPU_LITTLE_ENDIAN),y)
override CC += -mlittle-endian
override LD += -EL
...
ifeq ($(HAS_BIARCH),y)
override CC += -m$(CONFIG_WORD_SIZE)
override LD += -m elf$(CONFIG_WORD_SIZE)$(LDEMULATION)

But in the case of vdso64, ld command is gcc:

arch/powerpc/kernel/vdso64/Makefile:

cmd_vdso64ld = $(CC) $(c_flags) -Wl,-T $^ -o $@

So to  link, we use "gcc -mlittle-endian -m64"

and strace of "gcc -mlittle-endian -m64" gives me:

"/usr/libexec/gcc/ppc64-redhat-linux/5.1.1/collect2", [ ... "--oformat",
"elf32-powerpcle", "-m", "elf64lppc",...

So the format used to link is by default "elf32-powerpcle" (with the
emulation elf64lppc given by "-mlittle-endian -m64", I agree it seems
strange).

I think this is coming from the configuration of my gcc, "-dumpspecs"
gives me:

*link_target:
%{mlittle|mlittle-endian: --oformat
elf32-powerpcle;mbig|mbig-endian:;mcall-i960-old: --oformat
elf32-powerpcle;:}

When "ld" is called without "--oformat" it takes the format of the first
processed object ("elf64-powerpcle" in our case, it's why it works for
the other binaries of the kernel).

So at this point, I can:

1- either fix my compiler,
2- or fix the vdso64 linker command.

As all the others objects of the kernel are generated and linked
correctly with this build env, there is no reason to not choose 2- as 1-
is much more complex (at leasts for me = rebuild gcc whereas I just want
to build the kernel).

But, more generally, what I'm wondering is why we are using CC instead
of LD to link objects...

Laurent
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev