* [PATCH 1/3] kbuild, modpost: fix unexpected non-allocatable section when cross compiling
From: Sam Ravnborg @ 2009-05-04 11:59 UTC (permalink / raw)
To: LKML, linux-kbuild
Cc: Stephen Rothwell, Wolfgang Denk, Manuel Lauss, Anders Kaseorg,
linuxppc-dev, Sean MacLennan, Jean Delvare
In-Reply-To: <20090504115704.GA7134@uranus.ravnborg.org>
>From 7d875a02864a35532543897195dfea2235815df8 Mon Sep 17 00:00:00 2001
From: Anders Kaseorg <andersk@MIT.EDU>
Date: Sun, 3 May 2009 22:02:55 +0200
Subject: [PATCH 1/3] kbuild, modpost: fix unexpected non-allocatable section when cross compiling
The missing TO_NATIVE(sechdrs[i].sh_flags) was causing many
unexpected non-allocatable section warnings when cross-compiling
for an architecture with a different endianness.
Fix endianness of all the fields in the ELF header and
section headers, not just some of them so we are not
hit by this anohter time.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
Reported-by: Sean MacLennan <smaclennan@pikatech.com>
Tested-by: Sean MacLennan <smaclennan@pikatech.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
---
scripts/mod/modpost.c | 35 +++++++++++++++++++++++------------
1 files changed, 23 insertions(+), 12 deletions(-)
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 936b6f8..a5c17db 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -384,11 +384,19 @@ static int parse_elf(struct elf_info *info, const char *filename)
return 0;
}
/* Fix endianness in ELF header */
- hdr->e_shoff = TO_NATIVE(hdr->e_shoff);
- hdr->e_shstrndx = TO_NATIVE(hdr->e_shstrndx);
- hdr->e_shnum = TO_NATIVE(hdr->e_shnum);
- hdr->e_machine = TO_NATIVE(hdr->e_machine);
- hdr->e_type = TO_NATIVE(hdr->e_type);
+ hdr->e_type = TO_NATIVE(hdr->e_type);
+ hdr->e_machine = TO_NATIVE(hdr->e_machine);
+ hdr->e_version = TO_NATIVE(hdr->e_version);
+ hdr->e_entry = TO_NATIVE(hdr->e_entry);
+ hdr->e_phoff = TO_NATIVE(hdr->e_phoff);
+ hdr->e_shoff = TO_NATIVE(hdr->e_shoff);
+ hdr->e_flags = TO_NATIVE(hdr->e_flags);
+ hdr->e_ehsize = TO_NATIVE(hdr->e_ehsize);
+ hdr->e_phentsize = TO_NATIVE(hdr->e_phentsize);
+ hdr->e_phnum = TO_NATIVE(hdr->e_phnum);
+ hdr->e_shentsize = TO_NATIVE(hdr->e_shentsize);
+ hdr->e_shnum = TO_NATIVE(hdr->e_shnum);
+ hdr->e_shstrndx = TO_NATIVE(hdr->e_shstrndx);
sechdrs = (void *)hdr + hdr->e_shoff;
info->sechdrs = sechdrs;
@@ -402,13 +410,16 @@ static int parse_elf(struct elf_info *info, const char *filename)
/* Fix endianness in section headers */
for (i = 0; i < hdr->e_shnum; i++) {
- sechdrs[i].sh_type = TO_NATIVE(sechdrs[i].sh_type);
- sechdrs[i].sh_offset = TO_NATIVE(sechdrs[i].sh_offset);
- sechdrs[i].sh_size = TO_NATIVE(sechdrs[i].sh_size);
- sechdrs[i].sh_link = TO_NATIVE(sechdrs[i].sh_link);
- sechdrs[i].sh_name = TO_NATIVE(sechdrs[i].sh_name);
- sechdrs[i].sh_info = TO_NATIVE(sechdrs[i].sh_info);
- sechdrs[i].sh_addr = TO_NATIVE(sechdrs[i].sh_addr);
+ sechdrs[i].sh_name = TO_NATIVE(sechdrs[i].sh_name);
+ sechdrs[i].sh_type = TO_NATIVE(sechdrs[i].sh_type);
+ sechdrs[i].sh_flags = TO_NATIVE(sechdrs[i].sh_flags);
+ sechdrs[i].sh_addr = TO_NATIVE(sechdrs[i].sh_addr);
+ sechdrs[i].sh_offset = TO_NATIVE(sechdrs[i].sh_offset);
+ sechdrs[i].sh_size = TO_NATIVE(sechdrs[i].sh_size);
+ sechdrs[i].sh_link = TO_NATIVE(sechdrs[i].sh_link);
+ sechdrs[i].sh_info = TO_NATIVE(sechdrs[i].sh_info);
+ sechdrs[i].sh_addralign = TO_NATIVE(sechdrs[i].sh_addralign);
+ sechdrs[i].sh_entsize = TO_NATIVE(sechdrs[i].sh_entsize);
}
/* Find symbol table. */
for (i = 1; i < hdr->e_shnum; i++) {
--
1.6.3.rc3.40.g75b44
^ permalink raw reply related
* kbuild, modpost: fix "non-allocatable section" warnings
From: Sam Ravnborg @ 2009-05-04 11:57 UTC (permalink / raw)
To: LKML, linux-kbuild
Cc: Stephen Rothwell, Wolfgang Denk, Manuel Lauss, Anders Kaseorg,
linuxppc-dev, Sean MacLennan, Jean Delvare
It turned out there were at least three sources of
the "non-allocatable section" warning.
1) SUSE specific .comment section
2) endianness issues in elf header
3) additional debug sections
I have updated kbuild-fixes.git with
patches for all of the above.
But as we have seen three independent sources of this
warning within short time I expect there may be
yet-to-be-discovered issues.
The patches accumulated so far all looks trivially correct
and Jean and Sean has been quick to test them.
So unless something unexpected shows up I plan to push them
within a day or two.
I would like to see them in -next for a day or two first
in the hope that if other architectures has troubles
they will report this before it hits upstream.
Patches will follow for reference / testing.
Sam
^ permalink raw reply
* Re: [PATCH] i2c-cpm: Pass dev ptr to dma_*_coherent rather than NULL
From: Mark Ware @ 2009-05-03 23:58 UTC (permalink / raw)
To: Ben Dooks; +Cc: Linuxppc-dev Development, linux-i2c
In-Reply-To: <20090503222352.GB5750@fluff.org.uk>
Ben Dooks wrote:
> On Wed, Apr 29, 2009 at 08:43:14AM -0500, Kumar Gala wrote:
>> On Apr 22, 2009, at 4:56 PM, Ben Dooks wrote:
>>
>>> On Tue, Apr 21, 2009 at 10:11:51AM -0500, Kumar Gala wrote:
>>>> On Apr 21, 2009, at 7:49 AM, Mark Ware wrote:
>>>>
>>>>> Recent DMA changes result in a BUG() when NULL is passed to
>>>>> dma_alloc_coherent in place of a device.
>>>>>
>>>>> Signed-off-by: Mark Ware <mware@elphinstone.net>
>>>>> ---
>>>>>
>>>>> This patch fixes the BUG() during boot that has appeared during the
>>>>> 2.6.30 window. It has been tested and appears correct on my 8280
>>>>> based
>>>>> board.
>>>>> Sent to both linuxppc-dev and linux-i2c, since I'm not sure where it
>>>>> belongs.
>>>>>
>>>>>
>>>>> drivers/i2c/busses/i2c-cpm.c | 14 ++++++++------
>>>>> 1 files changed, 8 insertions(+), 6 deletions(-)
>>>> Acked-by: Kumar Gala <galak@kernel.crashing.org>
>>>>
>>>> Ben, I'm expecting you to pick this up unless you tell me otherwise.
>>> Yes.
>> This go in yet?
>
> I've had to do a manual apply due to some changes in the
> driver, so can someone please do a build of my git tree
> at:
>
> git://aeryn.fluff.org.uk/bjdooks/linux.git i2c-for-2630-rc5
>
> or tell me which arch and defconfig to build.
>
Fails to build, due to a typo. Once fixed (diff below), it builds
and tests OK on my MPC8280 based hardware
Thanks.
Mark
diff --git a/drivers/i2c/busses/i2c-cpm.c b/drivers/i2c/busses/i2c-cpm.c
index b4c0448..b5db8b8 100644
--- a/drivers/i2c/busses/i2c-cpm.c
+++ b/drivers/i2c/busses/i2c-cpm.c
@@ -585,7 +585,7 @@ static int __devinit cpm_i2c_setup(struct cpm_i2c *cpm)
out_muram:
for (i = 0; i < CPM_MAXBD; i++) {
if (cpm->rxbuf[i])
- dma_free_coherent(&cpm->ofdev->devL, CPM_MAX_READ + 1,
+ dma_free_coherent(&cpm->ofdev->dev, CPM_MAX_READ + 1,
cpm->rxbuf[i], cpm->rxdma[i]);
if (cpm->txbuf[i])
dma_free_coherent(&cpm->ofdev->dev, CPM_MAX_READ + 1,
^ permalink raw reply related
* Re: [PATCH] i2c-cpm: Pass dev ptr to dma_*_coherent rather than NULL
From: Ben Dooks @ 2009-05-03 22:23 UTC (permalink / raw)
To: Kumar Gala; +Cc: Linuxppc-dev Development, linux-i2c, Ben Dooks, Mark Ware
In-Reply-To: <AAD6564F-9D99-492B-8364-10A652F990DF@kernel.crashing.org>
On Wed, Apr 29, 2009 at 08:43:14AM -0500, Kumar Gala wrote:
>
> On Apr 22, 2009, at 4:56 PM, Ben Dooks wrote:
>
>> On Tue, Apr 21, 2009 at 10:11:51AM -0500, Kumar Gala wrote:
>>>
>>> On Apr 21, 2009, at 7:49 AM, Mark Ware wrote:
>>>
>>>> Recent DMA changes result in a BUG() when NULL is passed to
>>>> dma_alloc_coherent in place of a device.
>>>>
>>>> Signed-off-by: Mark Ware <mware@elphinstone.net>
>>>> ---
>>>>
>>>> This patch fixes the BUG() during boot that has appeared during the
>>>> 2.6.30 window. It has been tested and appears correct on my 8280
>>>> based
>>>> board.
>>>> Sent to both linuxppc-dev and linux-i2c, since I'm not sure where it
>>>> belongs.
>>>>
>>>>
>>>> drivers/i2c/busses/i2c-cpm.c | 14 ++++++++------
>>>> 1 files changed, 8 insertions(+), 6 deletions(-)
>>>
>>> Acked-by: Kumar Gala <galak@kernel.crashing.org>
>>>
>>> Ben, I'm expecting you to pick this up unless you tell me otherwise.
>>
>> Yes.
>
> This go in yet?
I've had to do a manual apply due to some changes in the
driver, so can someone please do a build of my git tree
at:
git://aeryn.fluff.org.uk/bjdooks/linux.git i2c-for-2630-rc5
or tell me which arch and defconfig to build.
--
Ben (ben@fluff.org, http://www.fluff.org/)
'a smiley only costs 4 bytes'
^ permalink raw reply
* Re: Porting the ibm_newemac driver to use phylib (and other PHY/MAC questions)
From: Benjamin Herrenschmidt @ 2009-05-03 22:14 UTC (permalink / raw)
To: Kyle Moffett; +Cc: netdev, Linux-Kernel@Vger. Kernel. Org, linuxppc-dev
In-Reply-To: <f73f7ab80905022126ud3225enc6409bd39b5b2eb8@mail.gmail.com>
On Sun, 2009-05-03 at 00:26 -0400, Kyle Moffett wrote:
> Ok, I've dug through the docs on the 460EPx (the CPU I'm using), and
> I'd like some confirmation of the following:
>
> * The EMAC hardware itself internally has its own dedicated
> MDIO/MDClk lines, driven by the STACR register.
Yes, though not all EMACs cells have this wired to anything. For
example, the 405EP has 2 EMACs but only EMAC0 has MDIO, which is
used to control both PHYs. Later variants multiplex the MDIOs via
a programmable switch in the ZMII or RGMII though.
> * On many/most cpus, there is only a single set of external
> MDIO/MDClk pins, driven either off the ZMII bridge or the RGMII
> bridge.
Yes, though on the very old ones, the ZMII bridge is effectively
invisible (if it exists at all) and only EMAC0 MDIO pins are wired out.
> * Both bridge-types have their own internal register for switching
> the external MDIO/MDClk pins between the two sets of internal
> EMAC<=>bridge links.
Yes.
> * Some SoCs have both an ZMII and an RGMII bridge, and the external
> MDIO/MDClk pins are only connected to one of the two bridges (How do I
> know which one? Alternatively, do I just program both and hope for
> the best?).
That's been my approach so far :-)
> * Some older SoCs simply export the MDIO/MDClk pins from one of their
> internal EMAC chips and don't bother with running it through the
> multiplexing bridge.
Yes.
> Are there any SoCs which actually export the MDIO/MDClk pins from
> both/all of their EMACs?
I don't know of such a beast.
Cheers,
Ben.
> Cheers,
> Kyle Moffett
^ permalink raw reply
* Re: [PATCH] powerpc: convert mace to netdev_ops
From: David Miller @ 2009-05-03 21:20 UTC (permalink / raw)
To: rbrito; +Cc: linuxppc-dev, paulus, linux-kernel, netdev
In-Reply-To: <20090503.141524.253766195.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Sun, 03 May 2009 14:15:24 -0700 (PDT)
> From: Rog=E9rio Brito <rbrito@ime.usp.br>
> Date: Sun, 3 May 2009 08:48:20 -0300
> =
>> I hope that this version is a slightly better fix to convert mace to=
>> netdev_ops.
>> =
>> This is against this morning's net-2.6 tree.
>> =
>> Signed-off-by: Rog=E9rio Brito <rbrito@ime.usp.br>
> =
> I'll apply this, thanks! I made one change however.
Oh, nevermind, it seems that MACE was already converted
to netdev_ops some time ago in the net-next-2.6 tree.
^ permalink raw reply
* Re: [PATCH] powerpc: convert mace to netdev_ops
From: David Miller @ 2009-05-03 21:15 UTC (permalink / raw)
To: rbrito; +Cc: linuxppc-dev, paulus, linux-kernel, netdev
In-Reply-To: <20090503114820.GA14926@ime.usp.br>
From: Rog=E9rio Brito <rbrito@ime.usp.br>
Date: Sun, 3 May 2009 08:48:20 -0300
> I hope that this version is a slightly better fix to convert mace to
> netdev_ops.
> =
> This is against this morning's net-2.6 tree.
> =
> Signed-off-by: Rog=E9rio Brito <rbrito@ime.usp.br>
I'll apply this, thanks! I made one change however.
> @@ -798,6 +807,13 @@ static irqreturn_t mace_interrupt(int irq, void =
*dev_id)
> return IRQ_HANDLED;
> }
> =
> +/*
> + * In the following, the parameter "data" is treated like a pointer,=
> + * which is probably OK for 32 bit arches, but not for 64.
> + *
> + * (Are mace's found on any newer machines??) -- rbrito
> + *
> + */
> static void mace_tx_timeout(unsigned long data)
> {
> struct net_device *dev =3D (struct net_device *) data;
I left this new comment out, as this is a common idiom (passing opaque
data as an 'unsigned long' argument to a callback) and casting it to a
pointer.
It also works perfectly fine on all 32-bit and 64-bit platforms.
^ permalink raw reply
* Re: unexpected non-allocatable section
From: Sam Ravnborg @ 2009-05-03 20:51 UTC (permalink / raw)
To: Sean MacLennan; +Cc: Stephen Rothwell, Wolfgang Denk, linuxppc-dev
In-Reply-To: <20090503163241.50bfcae4@lappy.seanm.ca>
On Sun, May 03, 2009 at 04:32:41PM -0400, Sean MacLennan wrote:
> On Sun, 3 May 2009 22:07:01 +0200
> "Sam Ravnborg" <sam@ravnborg.org> wrote:
>
> > On Sun, May 03, 2009 at 09:33:16PM +0200, Wolfgang Denk wrote:
>
> > > Which exact commands did you use to build the kenrel, and how did
> > > you set (and export?) the CROSS_COMPILE environment variable?
>
> export CROSS_COMPILE=ppc_4xxFP-
> export ARCH=powerpc
>
> The toolchain is in my path
>
> > > The thing is, that I cannot reproduce this - I tested it with
> > > v2.6.30-rc4, both with ELDK 4.1 (as you) and ELDK 4.2.
> > >
> > > Both build the kernel image without any such warnings.
> >
> > Anders already found the cause of this - it
> > was a missing endian conversion.
> > So you need to run this on a little endian target to
> > see it. And you need to do a full kernel build
> > so we run modpsot on vmlinux.
> >
> > I will push the patch in a few minutes.
>
> That patch gets rid of the warnings.
Thanks for the quick testing. I will add a "Tested-by: if I rebase the tree.
Sam
^ permalink raw reply
* Re: unexpected non-allocatable section
From: Sam Ravnborg @ 2009-05-03 20:51 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev, Stephen Rothwell, Sean MacLennan
In-Reply-To: <20090503201940.82D3083420E8@gemini.denx.de>
> I ran the tests on a LE machine:
>
> Linux gemini.denx.de 2.6.27.15-170.2.24.fc10.i686 #1 SMP Wed Feb 11 23:58:12 EST 2009 i686 i686 i386 GNU/Linux
>
> > I will push the patch in a few minutes.
> >
> > For reference it is below:
> >
> > Sam
> >
> > From: Anders Kaseorg <andersk@MIT.EDU>
> > Subject: [PATCH] kbuild, modpost: fix unexpected non-allocatable section when cross compiling
> >
> > The missing TO_NATIVE(sechdrs[i].sh_flags) was causing many
> > unexpected non-allocatable section warnings when cross-compiling
> > for an architecture with a different endianness.
>
> I'm confused. Why didn't I see this, then?
Maybe they just scrolled past the screen first time?
You need to do "rm vmlinux.o" to reproduce it.
The warnings are shown when we do section mismatch analysis on vmlinux.o
which is part of the final steps in creating vmlinux.
But you will force the check again if you only delete vmlinux.
You need to delete vmlinux.o to see them.
I hope this is the explanation - otherwise I have no good idea.
Sam
^ permalink raw reply
* Re: unexpected non-allocatable section
From: Sean MacLennan @ 2009-05-03 20:32 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Stephen Rothwell, Wolfgang Denk, linuxppc-dev
In-Reply-To: <20090503200701.GA32601@uranus.ravnborg.org>
On Sun, 3 May 2009 22:07:01 +0200
"Sam Ravnborg" <sam@ravnborg.org> wrote:
> On Sun, May 03, 2009 at 09:33:16PM +0200, Wolfgang Denk wrote:
> > Which exact commands did you use to build the kenrel, and how did
> > you set (and export?) the CROSS_COMPILE environment variable?
export CROSS_COMPILE=ppc_4xxFP-
export ARCH=powerpc
The toolchain is in my path
> > The thing is, that I cannot reproduce this - I tested it with
> > v2.6.30-rc4, both with ELDK 4.1 (as you) and ELDK 4.2.
> >
> > Both build the kernel image without any such warnings.
>
> Anders already found the cause of this - it
> was a missing endian conversion.
> So you need to run this on a little endian target to
> see it. And you need to do a full kernel build
> so we run modpsot on vmlinux.
>
> I will push the patch in a few minutes.
That patch gets rid of the warnings.
Cheers,
Sean
^ permalink raw reply
* Re: unexpected non-allocatable section
From: Wolfgang Denk @ 2009-05-03 20:19 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: linuxppc-dev, Stephen Rothwell, Sean MacLennan
In-Reply-To: <20090503200701.GA32601@uranus.ravnborg.org>
Dear Sam,
in message <20090503200701.GA32601@uranus.ravnborg.org> you wrote:
>
> > The thing is, that I cannot reproduce this - I tested it with
> > v2.6.30-rc4, both with ELDK 4.1 (as you) and ELDK 4.2.
> >
> > Both build the kernel image without any such warnings.
>
> Anders already found the cause of this - it
> was a missing endian conversion.
> So you need to run this on a little endian target to
> see it. And you need to do a full kernel build
> so we run modpsot on vmlinux.
On a little endian target? I guess you mean LE build host, because the
target (warp board = ppc44x) is definitely big endian?
I ran the tests on a LE machine:
Linux gemini.denx.de 2.6.27.15-170.2.24.fc10.i686 #1 SMP Wed Feb 11 23:58:12 EST 2009 i686 i686 i386 GNU/Linux
> I will push the patch in a few minutes.
>
> For reference it is below:
>
> Sam
>
> From: Anders Kaseorg <andersk@MIT.EDU>
> Subject: [PATCH] kbuild, modpost: fix unexpected non-allocatable section when cross compiling
>
> The missing TO_NATIVE(sechdrs[i].sh_flags) was causing many
> unexpected non-allocatable section warnings when cross-compiling
> for an architecture with a different endianness.
I'm confused. Why didn't I see this, then?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
People have one thing in common: they are all different.
^ permalink raw reply
* Re: unexpected non-allocatable section
From: Sam Ravnborg @ 2009-05-03 20:07 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev, Stephen Rothwell, Sean MacLennan
In-Reply-To: <20090503193316.E72BC83420E8@gemini.denx.de>
On Sun, May 03, 2009 at 09:33:16PM +0200, Wolfgang Denk wrote:
> Dear Sean MacLennan,
>
> In message <20090503123959.0cc5c967@lappy.seanm.ca> you wrote:
> >
> > > What gcc, binutils versions and config are you using?
> >
> > gcc version 4.0.0 (DENX ELDK 4.1 4.0.0)
> > GNU assembler version 2.16.1 (powerpc-linux) using BFD version 2.16.1
> >
> > And this is all running on the Warp with a 440EP.
>
> Which exact commands did you use to build the kenrel, and how did you
> set (and export?) the CROSS_COMPILE environment variable?
>
> The thing is, that I cannot reproduce this - I tested it with
> v2.6.30-rc4, both with ELDK 4.1 (as you) and ELDK 4.2.
>
> Both build the kernel image without any such warnings.
Anders already found the cause of this - it
was a missing endian conversion.
So you need to run this on a little endian target to
see it. And you need to do a full kernel build
so we run modpsot on vmlinux.
I will push the patch in a few minutes.
For reference it is below:
Sam
From: Anders Kaseorg <andersk@MIT.EDU>
Subject: [PATCH] kbuild, modpost: fix unexpected non-allocatable section when cross compiling
The missing TO_NATIVE(sechdrs[i].sh_flags) was causing many
unexpected non-allocatable section warnings when cross-compiling
for an architecture with a different endianness.
Fix endianness of all the fields in the ELF header and
section headers, not just some of them so we are not
hit by this anohter time.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
---
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 936b6f8..a5c17db 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -384,11 +384,19 @@ static int parse_elf(struct elf_info *info, const char *filename)
return 0;
}
/* Fix endianness in ELF header */
- hdr->e_shoff = TO_NATIVE(hdr->e_shoff);
- hdr->e_shstrndx = TO_NATIVE(hdr->e_shstrndx);
- hdr->e_shnum = TO_NATIVE(hdr->e_shnum);
- hdr->e_machine = TO_NATIVE(hdr->e_machine);
- hdr->e_type = TO_NATIVE(hdr->e_type);
+ hdr->e_type = TO_NATIVE(hdr->e_type);
+ hdr->e_machine = TO_NATIVE(hdr->e_machine);
+ hdr->e_version = TO_NATIVE(hdr->e_version);
+ hdr->e_entry = TO_NATIVE(hdr->e_entry);
+ hdr->e_phoff = TO_NATIVE(hdr->e_phoff);
+ hdr->e_shoff = TO_NATIVE(hdr->e_shoff);
+ hdr->e_flags = TO_NATIVE(hdr->e_flags);
+ hdr->e_ehsize = TO_NATIVE(hdr->e_ehsize);
+ hdr->e_phentsize = TO_NATIVE(hdr->e_phentsize);
+ hdr->e_phnum = TO_NATIVE(hdr->e_phnum);
+ hdr->e_shentsize = TO_NATIVE(hdr->e_shentsize);
+ hdr->e_shnum = TO_NATIVE(hdr->e_shnum);
+ hdr->e_shstrndx = TO_NATIVE(hdr->e_shstrndx);
sechdrs = (void *)hdr + hdr->e_shoff;
info->sechdrs = sechdrs;
@@ -402,13 +410,16 @@ static int parse_elf(struct elf_info *info, const char *filename)
/* Fix endianness in section headers */
for (i = 0; i < hdr->e_shnum; i++) {
- sechdrs[i].sh_type = TO_NATIVE(sechdrs[i].sh_type);
- sechdrs[i].sh_offset = TO_NATIVE(sechdrs[i].sh_offset);
- sechdrs[i].sh_size = TO_NATIVE(sechdrs[i].sh_size);
- sechdrs[i].sh_link = TO_NATIVE(sechdrs[i].sh_link);
- sechdrs[i].sh_name = TO_NATIVE(sechdrs[i].sh_name);
- sechdrs[i].sh_info = TO_NATIVE(sechdrs[i].sh_info);
- sechdrs[i].sh_addr = TO_NATIVE(sechdrs[i].sh_addr);
+ sechdrs[i].sh_name = TO_NATIVE(sechdrs[i].sh_name);
+ sechdrs[i].sh_type = TO_NATIVE(sechdrs[i].sh_type);
+ sechdrs[i].sh_flags = TO_NATIVE(sechdrs[i].sh_flags);
+ sechdrs[i].sh_addr = TO_NATIVE(sechdrs[i].sh_addr);
+ sechdrs[i].sh_offset = TO_NATIVE(sechdrs[i].sh_offset);
+ sechdrs[i].sh_size = TO_NATIVE(sechdrs[i].sh_size);
+ sechdrs[i].sh_link = TO_NATIVE(sechdrs[i].sh_link);
+ sechdrs[i].sh_info = TO_NATIVE(sechdrs[i].sh_info);
+ sechdrs[i].sh_addralign = TO_NATIVE(sechdrs[i].sh_addralign);
+ sechdrs[i].sh_entsize = TO_NATIVE(sechdrs[i].sh_entsize);
}
/* Find symbol table. */
for (i = 1; i < hdr->e_shnum; i++) {
^ permalink raw reply related
* Re: unexpected non-allocatable section
From: Wolfgang Denk @ 2009-05-03 19:33 UTC (permalink / raw)
To: Sean MacLennan; +Cc: Stephen Rothwell, Sam Ravnborg, linuxppc-dev
In-Reply-To: <20090503123959.0cc5c967@lappy.seanm.ca>
Dear Sean MacLennan,
In message <20090503123959.0cc5c967@lappy.seanm.ca> you wrote:
>
> > What gcc, binutils versions and config are you using?
>
> gcc version 4.0.0 (DENX ELDK 4.1 4.0.0)
> GNU assembler version 2.16.1 (powerpc-linux) using BFD version 2.16.1
>
> And this is all running on the Warp with a 440EP.
Which exact commands did you use to build the kenrel, and how did you
set (and export?) the CROSS_COMPILE environment variable?
The thing is, that I cannot reproduce this - I tested it with
v2.6.30-rc4, both with ELDK 4.1 (as you) and ELDK 4.2.
Both build the kernel image without any such warnings.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
The software required `Windows 95 or better', so I installed Linux.
^ permalink raw reply
* Re: help with MPC8272ADS board
From: Wolfgang Denk @ 2009-05-03 19:26 UTC (permalink / raw)
To: Landau, Bracha; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <065A7D06F7D4E546A18E80E08D066E1811892DD86B@ILMA1.IL.NDS.COM>
Dear Bracha,
In message <065A7D06F7D4E546A18E80E08D066E1811892DD86B@ILMA1.IL.NDS.COM> you wrote:
>
> I'm trying to get the MPC8272ADS evaluation board up and running with
> the latest versions of u-boot and Denx linux (2.6.24).
2.6.24 is actually very old and not even close to latest. "Latest" is
(as I'm typing this) v2.6.30-rc4.
> I use the device tree file (mpc8272ads.dts) provided. Based on
> another post, I updated the MPC8260ADS.h file, changing OF_CPU from
> "cpu@0<mailto:cpu@0>" to "PowerPC,8272@0", because I was getting an
> error.
No such changes should be necessary.
I just tried this (using both the kernel.org tree, and our
linux-2.6-denx repository), with the same results (i. e. zero build
problems):
$ export CROSS_COMPILE=ppc_6xx-
$ export ARCH=powerpc
$ make CROSS_COMPILE=ppc_6xx- ARCH=powerpc mpc8272_ads_defconfig
$ make -j6 CROSS_COMPILE=ppc_6xx- ARCH=powerpc uImage
$ make mpc8272ads.dtb
Then use the images in "arch/powerpc/boot/uImage" and
"arch/powerpc/boot/mpc8272ads.dtb", resp.
[Sorry, I cannot test this myself as we don't have a mpc8272_ads board
in our lab.]
> I tried booting both using a cuImage (cuImage.mpc8272ads) and a
> uImage with a device tree blob. Neither boot was successful, with no
> helpful information printed to the serial port.
>
> Is there any change that has to be made in order to get the board to
> boot?
Maybe you did not pass the right "console=" boot argument? Keep in
ind that the serial ports are named "ttyCPM*" now, not "ttyS*" as it
used to be with very old kernel versions.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
I thought my people would grow tired of killing. But you were right,
they see it is easier than trading. And it has its pleasures. I feel
it myself. Like the hunt, but with richer rewards.
-- Apella, "A Private Little War", stardate 4211.8
^ permalink raw reply
* Re: unexpected non-allocatable section
From: Sean MacLennan @ 2009-05-03 16:39 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, Sam Ravnborg
In-Reply-To: <20090503204546.691ec6e7.sfr@canb.auug.org.au>
On Sun, 3 May 2009 20:45:46 +1000
"Stephen Rothwell" <sfr@canb.auug.org.au> wrote:
> What gcc, binutils versions and config are you using?
gcc version 4.0.0 (DENX ELDK 4.1 4.0.0)
GNU assembler version 2.16.1 (powerpc-linux) using BFD version 2.16.1
And this is all running on the Warp with a 440EP.
Cheers,
Sean
^ permalink raw reply
* Re: Next April 28: boot failure on PowerPC with SLQB
From: Pekka Enberg @ 2009-05-03 11:51 UTC (permalink / raw)
To: Nick Piggin
Cc: Stephen Rothwell, Christoph Lameter, linux-kernel, linuxppc-dev,
linux-next
In-Reply-To: <20090430141029.GG6900@wotan.suse.de>
On Thu, 2009-04-30 at 16:10 +0200, Nick Piggin wrote:
> On Fri, May 01, 2009 at 12:00:33AM +1000, Stephen Rothwell wrote:
> > Hi Nick,
> >
> > On Thu, 30 Apr 2009 15:05:42 +0200 Nick Piggin <npiggin@suse.de> wrote:
> > >
> > > Hmm, this might do it. The following code now passes some stress testing
> > > in a userspace harness wheras before it did not (and was obviously wrong).
> >
> > Indeed that allows it to boot fine. Thanks.
> >
> > Tested-by: Stephen Rothwell <sfr@canb.auug.org.au>
>
> Great, thanks for reporting and testing. This one is especially
> important because it is basically scribbling on random memory
> :( Pekka, please apply.
Applied, thanks!
^ permalink raw reply
* Re: Next April 28: boot failure on PowerPC with SLQB
From: Pekka Enberg @ 2009-05-03 11:51 UTC (permalink / raw)
To: avorontsov
Cc: Nick Piggin, Stephen Rothwell, Christoph Lameter, linux-kernel,
linuxppc-dev, linux-next
In-Reply-To: <20090430141013.GA17480@oksana.dev.rtsoft.ru>
On Thu, 2009-04-30 at 18:10 +0400, Anton Vorontsov wrote:
> > @@ -2194,16 +2197,16 @@ static void *kmem_cache_dyn_array_alloc(
> > * never get freed by definition so we can do it rather
> > * simply.
> > */
> > - if (!nextmem) {
> > - nextmem = alloc_pages_exact(size, GFP_KERNEL);
> > - if (!nextmem)
> > - return NULL;
> > + if (size > nextleft) {
> > + nextmem = alloc_pages_exact(size, GFP_KERNEL);
> > + if (!nextmem)
> > + return NULL;
>
> Cosmetic issue: spaces instead of tabs are used on these
> three lines.
I fixed that up. Thanks!
^ permalink raw reply
* [PATCH] powerpc: convert mace to netdev_ops
From: Rogério Brito @ 2009-05-03 11:48 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev, paulus, linux-kernel, netdev
In-Reply-To: <20090427.054258.16622932.davem@davemloft.net>
Hi, Dave.
On Apr 27 2009, David Miller wrote:
> You can fix the mace_set_timeout() function arguments by having
> a helper function that simply wraps around it and provides the
> second expection of argument types.
I hope that this version is a slightly better fix to convert mace to
netdev_ops.
This is against this morning's net-2.6 tree.
Signed-off-by: Rogério Brito <rbrito@ime.usp.br>
---
diff --git a/drivers/net/mace.c b/drivers/net/mace.c
index feebbd9..03a179d 100644
--- a/drivers/net/mace.c
+++ b/drivers/net/mace.c
@@ -89,6 +89,19 @@ static inline void dbdma_reset(volatile struct dbdma_regs __iomem *dma);
static inline void mace_clean_rings(struct mace_data *mp);
static void __mace_set_address(struct net_device *dev, void *addr);
+/* Conversion to netdev_ops. */
+static const struct net_device_ops mace_netdev_ops = {
+ .ndo_open = mace_open,
+ .ndo_stop = mace_close,
+ .ndo_start_xmit = mace_xmit_start,
+ .ndo_tx_timeout = mace_tx_timeout,
+ .ndo_set_multicast_list = mace_set_multicast,
+ .ndo_set_mac_address = mace_set_address,
+ .ndo_change_mtu = eth_change_mtu,
+ .ndo_set_mac_address = eth_mac_addr,
+ .ndo_validate_addr = eth_validate_addr,
+};
+
/*
* If we can't get a skbuff when we need it, we use this area for DMA.
*/
@@ -207,11 +220,7 @@ static int __devinit mace_probe(struct macio_dev *mdev, const struct of_device_i
}
}
- dev->open = mace_open;
- dev->stop = mace_close;
- dev->hard_start_xmit = mace_xmit_start;
- dev->set_multicast_list = mace_set_multicast;
- dev->set_mac_address = mace_set_address;
+ dev->netdev_ops = &mace_netdev_ops;
/*
* Most of what is below could be moved to mace_open()
@@ -798,6 +807,13 @@ static irqreturn_t mace_interrupt(int irq, void *dev_id)
return IRQ_HANDLED;
}
+/*
+ * In the following, the parameter "data" is treated like a pointer,
+ * which is probably OK for 32 bit arches, but not for 64.
+ *
+ * (Are mace's found on any newer machines??) -- rbrito
+ *
+ */
static void mace_tx_timeout(unsigned long data)
{
struct net_device *dev = (struct net_device *) data;
--
Rogério Brito : rbrito@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
^ permalink raw reply related
* Re: unexpected non-allocatable section
From: Stephen Rothwell @ 2009-05-03 10:45 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev, Sam Ravnborg
In-Reply-To: <20090502224126.641c63bf@lappy.seanm.ca>
[-- Attachment #1: Type: text/plain, Size: 4314 bytes --]
Hi Sean,
On Sat, 2 May 2009 22:41:26 -0400 Sean MacLennan <smaclennan@pikatech.com> wrote:
>
> Latest pull from Linus' git.
>
> Cheers,
> Sean
>
> WARNING: vmlinux.o (.text): unexpected non-allocatable section.
> Did you forget to use "ax"/"aw" in a .S file?
> Note that for example <linux/init.h> contains
> section definitions for use in .S files.
>
> WARNING: vmlinux.o (.head.text): unexpected non-allocatable section.
> WARNING: vmlinux.o (.init.text): unexpected non-allocatable section.
> WARNING: vmlinux.o (.ref.text): unexpected non-allocatable section.
> WARNING: vmlinux.o (.cpuinit.text): unexpected non-allocatable section.
> WARNING: vmlinux.o (.sched.text): unexpected non-allocatable section.
> WARNING: vmlinux.o (.meminit.text): unexpected non-allocatable section.
> WARNING: vmlinux.o (.exit.text): unexpected non-allocatable section.
> WARNING: vmlinux.o (.devexit.text): unexpected non-allocatable section.
> WARNING: vmlinux.o (.devinit.text): unexpected non-allocatable section.
> WARNING: vmlinux.o (.rodata): unexpected non-allocatable section.
> WARNING: vmlinux.o (__param): unexpected non-allocatable section.
> WARNING: vmlinux.o (__ksymtab): unexpected non-allocatable section.
> WARNING: vmlinux.o (__ksymtab_strings): unexpected non-allocatable section.
> WARNING: vmlinux.o (.rodata.str1.4): unexpected non-allocatable section.
> WARNING: vmlinux.o (__bug_table): unexpected non-allocatable section.
> WARNING: vmlinux.o (__ksymtab_gpl): unexpected non-allocatable section.
> WARNING: vmlinux.o (.init.ramfs): unexpected non-allocatable section.
> WARNING: vmlinux.o (__ex_table): unexpected non-allocatable section.
> WARNING: vmlinux.o (.kprobes.text): unexpected non-allocatable section.
> WARNING: vmlinux.o (__ftr_alt_97): unexpected non-allocatable section.
> WARNING: vmlinux.o (__ftr_fixup): unexpected non-allocatable section.
> WARNING: vmlinux.o (.rodata.cst4): unexpected non-allocatable section.
> WARNING: vmlinux.o (.fixup): unexpected non-allocatable section.
> WARNING: vmlinux.o (.data): unexpected non-allocatable section.
> WARNING: vmlinux.o (.init.setup): unexpected non-allocatable section.
> WARNING: vmlinux.o (.init.data): unexpected non-allocatable section.
> WARNING: vmlinux.o (.data.read_mostly): unexpected non-allocatable section.
> WARNING: vmlinux.o (.initcallrootfs.init): unexpected non-allocatable section.
> WARNING: vmlinux.o (.initcall3.init): unexpected non-allocatable section.
> WARNING: vmlinux.o (.data.page_aligned): unexpected non-allocatable section.
> WARNING: vmlinux.o (.data.init_task): unexpected non-allocatable section.
> WARNING: vmlinux.o (.initcall6.init): unexpected non-allocatable section.
> WARNING: vmlinux.o (.initcall4.init): unexpected non-allocatable section.
> WARNING: vmlinux.o (.cpuinit.data): unexpected non-allocatable section.
> WARNING: vmlinux.o (.initcall2.init): unexpected non-allocatable section.
> WARNING: vmlinux.o (.con_initcall.init): unexpected non-allocatable section.
> WARNING: vmlinux.o (.initcall7.init): unexpected non-allocatable section.
> WARNING: vmlinux.o (.machine.desc): unexpected non-allocatable section.
> WARNING: vmlinux.o (.data.cacheline_aligned): unexpected non-allocatable section.
> WARNING: vmlinux.o (.initcallearly.init): unexpected non-allocatable section.
> WARNING: vmlinux.o (.initcall1.init): unexpected non-allocatable section.
> WARNING: vmlinux.o (.initcall5.init): unexpected non-allocatable section.
> WARNING: vmlinux.o (.ref.data): unexpected non-allocatable section.
> WARNING: vmlinux.o (.meminit.data): unexpected non-allocatable section.
> WARNING: vmlinux.o (.exitcall.exit): unexpected non-allocatable section.
> WARNING: vmlinux.o (.init.rodata): unexpected non-allocatable section.
> WARNING: vmlinux.o (.devinit.data): unexpected non-allocatable section.
> WARNING: vmlinux.o (.initcall0.init): unexpected non-allocatable section.
> WARNING: vmlinux.o (.initcall7s.init): unexpected non-allocatable section.
> WARNING: vmlinux.o (.sdata): unexpected non-allocatable section.
[Quoted in full for Sam's benefit]
What gcc, binutils versions and config ae you using?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* help with MPC8272ADS board
From: Landau, Bracha @ 2009-05-03 7:16 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
[-- Attachment #1: Type: text/plain, Size: 1848 bytes --]
Hi,
I'm trying to get the MPC8272ADS evaluation board up and running with the latest versions of u-boot and Denx linux (2.6.24).
I use the device tree file (mpc8272ads.dts) provided. Based on another post, I updated the MPC8260ADS.h file, changing OF_CPU from "cpu@0<mailto:cpu@0>" to "PowerPC,8272@0", because I was getting an error.
I tried booting both using a cuImage (cuImage.mpc8272ads) and a uImage with a device tree blob. Neither boot was successful, with no helpful information printed to the serial port.
Is there any change that has to be made in order to get the board to boot?
Bracha Landau
________________________________
This e-mail is confidential, the property of NDS Ltd and intended for the addressee only. Any dissemination, copying or distribution of this message or any attachments by anyone other than the intended recipient is strictly prohibited. If you have received this message in error, please immediately notify the postmaster@nds.com and destroy the original message. Messages sent to and from NDS may be monitored. NDS cannot guarantee any message delivery method is secure or error-free. Information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. We do not accept responsibility for any errors or omissions in this message and/or attachment that arise as a result of transmission. You should carry out your own virus checks before opening any attachment. Any views or opinions presented are solely those of the author and do not necessarily represent those of NDS.
To protect the environment please do not print this e-mail unless necessary.
NDS Limited Registered Office: One London Road, Staines,Middlesex TW18 4EX, United Kingdom. A company registered in England and Wales Registered no. 3080780 VAT no. GB 603 8808 40-00
[-- Attachment #2: Type: text/html, Size: 3838 bytes --]
^ permalink raw reply
* Re: unexpected non-allocatable section
From: Sean MacLennan @ 2009-05-03 7:04 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20090502224126.641c63bf@lappy.seanm.ca>
b614a697dc17dff82f140d72d21a095f810fa7fb is first bad commit
commit b614a697dc17dff82f140d72d21a095f810fa7fb
Author: Anders Kaseorg <andersk@mit.edu>
Date: Thu Apr 23 16:49:33 2009 -0400
kbuild, modpost: Check the section flags, to catch missing "ax"/"aw"
When you put
.section ".foo"
in an assembly file instead of
.section "foo", "ax"
, one of the possible symptoms is that modpost will see an
ld-generated section name ".foo.1" in section_rel() or section_rela().
But this heuristic has two problems: it will miss a bad section that
has no relocations, and it will incorrectly flag many gcc-generated
sections as bad when compiling with -ffunction-sections
-fdata-sections.
On mips it fixes a lot of bogus warnings with gcc 4.4.0 lije this one:
WARNING: crypto/cryptd.o (.text.T.349): unexpected section name.
So instead of checking whether the section name matches a particular
pattern, we directly check for a missing SHF_ALLOC in the section
flags.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
Tested-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
:040000 040000 9931d6ed1b6f9e836517162b15e757c8ad13d69e f1134de951b415eb7f5831898c827daf93c96c1a M scripts
^ permalink raw reply
* Re: Porting the ibm_newemac driver to use phylib (and other PHY/MAC questions)
From: Kyle Moffett @ 2009-05-03 4:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: netdev, Linux-Kernel@Vger. Kernel. Org, linuxppc-dev
In-Reply-To: <f73f7ab80904301521x16effa0ar2d4756daceada122@mail.gmail.com>
On Thu, Apr 30, 2009 at 6:21 PM, Kyle Moffett <kyle@moffetthome.net> wrote:
>>> I'm also curious about the intent of the "mdio_instance" pointer (IE:
>>> the "mdio-device" property). =C2=A0Is that used when all the PHY device=
s
>>> are attached to the MDIO bus of only one of the (multiple) emac
>>> devices?
>>
>> It's common especially on older SoCs using EMAC to have only one of
>> the EMAC instance with an MDIO bus for configuring the PHYs. This is one
>> of the reasons why I have the mutex in the low level MDIO access
>> routines since 2 EMACs can try to talk to the same MDIO, and this is the
>> problem I had with phylib back then which was doing everything in atomic
>> contexts.
>
> Ok, good, the current mdiobus code seems to make handling this a good
> deal easier.
Ok, I've dug through the docs on the 460EPx (the CPU I'm using), and
I'd like some confirmation of the following:
* The EMAC hardware itself internally has its own dedicated
MDIO/MDClk lines, driven by the STACR register.
* On many/most cpus, there is only a single set of external
MDIO/MDClk pins, driven either off the ZMII bridge or the RGMII
bridge.
* Both bridge-types have their own internal register for switching
the external MDIO/MDClk pins between the two sets of internal
EMAC<=3D>bridge links.
* Some SoCs have both an ZMII and an RGMII bridge, and the external
MDIO/MDClk pins are only connected to one of the two bridges (How do I
know which one? Alternatively, do I just program both and hope for
the best?).
* Some older SoCs simply export the MDIO/MDClk pins from one of their
internal EMAC chips and don't bother with running it through the
multiplexing bridge.
Are there any SoCs which actually export the MDIO/MDClk pins from
both/all of their EMACs?
Cheers,
Kyle Moffett
^ permalink raw reply
* unexpected non-allocatable section
From: Sean MacLennan @ 2009-05-03 2:41 UTC (permalink / raw)
To: linuxppc-dev
Latest pull from Linus' git.
Cheers,
Sean
WARNING: vmlinux.o (.text): unexpected non-allocatable section.
Did you forget to use "ax"/"aw" in a .S file?
Note that for example <linux/init.h> contains
section definitions for use in .S files.
WARNING: vmlinux.o (.head.text): unexpected non-allocatable section.
WARNING: vmlinux.o (.init.text): unexpected non-allocatable section.
WARNING: vmlinux.o (.ref.text): unexpected non-allocatable section.
WARNING: vmlinux.o (.cpuinit.text): unexpected non-allocatable section.
WARNING: vmlinux.o (.sched.text): unexpected non-allocatable section.
WARNING: vmlinux.o (.meminit.text): unexpected non-allocatable section.
WARNING: vmlinux.o (.exit.text): unexpected non-allocatable section.
WARNING: vmlinux.o (.devexit.text): unexpected non-allocatable section.
WARNING: vmlinux.o (.devinit.text): unexpected non-allocatable section.
WARNING: vmlinux.o (.rodata): unexpected non-allocatable section.
WARNING: vmlinux.o (__param): unexpected non-allocatable section.
WARNING: vmlinux.o (__ksymtab): unexpected non-allocatable section.
WARNING: vmlinux.o (__ksymtab_strings): unexpected non-allocatable section.
WARNING: vmlinux.o (.rodata.str1.4): unexpected non-allocatable section.
WARNING: vmlinux.o (__bug_table): unexpected non-allocatable section.
WARNING: vmlinux.o (__ksymtab_gpl): unexpected non-allocatable section.
WARNING: vmlinux.o (.init.ramfs): unexpected non-allocatable section.
WARNING: vmlinux.o (__ex_table): unexpected non-allocatable section.
WARNING: vmlinux.o (.kprobes.text): unexpected non-allocatable section.
WARNING: vmlinux.o (__ftr_alt_97): unexpected non-allocatable section.
WARNING: vmlinux.o (__ftr_fixup): unexpected non-allocatable section.
WARNING: vmlinux.o (.rodata.cst4): unexpected non-allocatable section.
WARNING: vmlinux.o (.fixup): unexpected non-allocatable section.
WARNING: vmlinux.o (.data): unexpected non-allocatable section.
WARNING: vmlinux.o (.init.setup): unexpected non-allocatable section.
WARNING: vmlinux.o (.init.data): unexpected non-allocatable section.
WARNING: vmlinux.o (.data.read_mostly): unexpected non-allocatable section.
WARNING: vmlinux.o (.initcallrootfs.init): unexpected non-allocatable section.
WARNING: vmlinux.o (.initcall3.init): unexpected non-allocatable section.
WARNING: vmlinux.o (.data.page_aligned): unexpected non-allocatable section.
WARNING: vmlinux.o (.data.init_task): unexpected non-allocatable section.
WARNING: vmlinux.o (.initcall6.init): unexpected non-allocatable section.
WARNING: vmlinux.o (.initcall4.init): unexpected non-allocatable section.
WARNING: vmlinux.o (.cpuinit.data): unexpected non-allocatable section.
WARNING: vmlinux.o (.initcall2.init): unexpected non-allocatable section.
WARNING: vmlinux.o (.con_initcall.init): unexpected non-allocatable section.
WARNING: vmlinux.o (.initcall7.init): unexpected non-allocatable section.
WARNING: vmlinux.o (.machine.desc): unexpected non-allocatable section.
WARNING: vmlinux.o (.data.cacheline_aligned): unexpected non-allocatable section.
WARNING: vmlinux.o (.initcallearly.init): unexpected non-allocatable section.
WARNING: vmlinux.o (.initcall1.init): unexpected non-allocatable section.
WARNING: vmlinux.o (.initcall5.init): unexpected non-allocatable section.
WARNING: vmlinux.o (.ref.data): unexpected non-allocatable section.
WARNING: vmlinux.o (.meminit.data): unexpected non-allocatable section.
WARNING: vmlinux.o (.exitcall.exit): unexpected non-allocatable section.
WARNING: vmlinux.o (.init.rodata): unexpected non-allocatable section.
WARNING: vmlinux.o (.devinit.data): unexpected non-allocatable section.
WARNING: vmlinux.o (.initcall0.init): unexpected non-allocatable section.
WARNING: vmlinux.o (.initcall7s.init): unexpected non-allocatable section.
WARNING: vmlinux.o (.sdata): unexpected non-allocatable section.
^ permalink raw reply
* Re: [PATCH 1/3] powerpc, Makefile: Make it possible to safely select CONFIG_FRAME_POINTER
From: Steven Rostedt @ 2009-05-03 2:04 UTC (permalink / raw)
To: Segher Boessenkool
Cc: linux-kernel, linuxppc-dev, Paul Mackerras, Ingo Molnar,
Sam Ravnborg
In-Reply-To: <68B2EF73-0FD2-41F9-966B-9A54965AFBA6@kernel.crashing.org>
On Sat, 2009-05-02 at 21:48 +0200, Segher Boessenkool wrote:
> > This patch introduces HAVE_NORMAL_FRAME_POINTER Kconfig symbol. When
> > defined, the top level Makefile won't add -fno-omit-frame-pointer
> > cflag (the flag is useless for PowerPC kernels, and also makes gcc
> > generate wrong code).
>
> > +++ b/arch/powerpc/Kconfig
>
> > + select HAVE_NORMAL_FRAME_POINTER
>
> > +config HAVE_NORMAL_FRAME_POINTER
> > + bool
> > + help
> > + Architectures should select this symbol if their ABI implies
> > + having a frame pointer.
>
> I am totally confused what you call a frame pointer here.
> None of the relevant PowerPC ABIs have a frame pointer
> separate from the stack pointer; the compiler can create
> one, of course. A better config symbol name and help text
> would help understand this patch :-)
Yeah, I agree. This needs a better description. I only know what's going
on because I was there for the start of the discussion.
But just to be sure, this is what I think is happening.
When we add "-pg" to gcc, it automatically causes frame pointers to be
used.
But with PPC, it always has frame pointers and there's no problem.
But with Linux, when you add CONFIG_FRAME_POINTER, it automatically
adds: -fno-omit-frame-pointer. Thus the config will add
"-fomit-frame-pointer" when CONFIG_FRAME_POINTER is not set, or it will
add "-fno-omit-frame-pointer" when it is set.
The problem with PPC is that "-fno-omit-frame-pointer" is buggy and
causes gcc to produce bad code.
Perhaps a better name would be:
HAVE_FRAME_POINTER_AS_DEFAULT
??
Or am I totally wrong in my analysis?
-- Steve
^ permalink raw reply
* Re: [PATCH 1/3] powerpc, Makefile: Make it possible to safely select CONFIG_FRAME_POINTER
From: Segher Boessenkool @ 2009-05-02 19:48 UTC (permalink / raw)
To: Anton Vorontsov
Cc: linux-kernel, linuxppc-dev, Steven Rostedt, Paul Mackerras,
Ingo Molnar, Sam Ravnborg
In-Reply-To: <20090502001421.GA9342@oksana.dev.rtsoft.ru>
> This patch introduces HAVE_NORMAL_FRAME_POINTER Kconfig symbol. When
> defined, the top level Makefile won't add -fno-omit-frame-pointer
> cflag (the flag is useless for PowerPC kernels, and also makes gcc
> generate wrong code).
> +++ b/arch/powerpc/Kconfig
> + select HAVE_NORMAL_FRAME_POINTER
> +config HAVE_NORMAL_FRAME_POINTER
> + bool
> + help
> + Architectures should select this symbol if their ABI implies
> + having a frame pointer.
I am totally confused what you call a frame pointer here.
None of the relevant PowerPC ABIs have a frame pointer
separate from the stack pointer; the compiler can create
one, of course. A better config symbol name and help text
would help understand this patch :-)
Segher
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox