[patch 1/1] ia64: increase .data.patch offset

[patch 1/1] ia64: increase .data.patch offset

[akpm]

From: Andrew Morton <akpm@linux-foundation.org>

I get this:

/opt/crosstool/gcc-3.4.5-glibc-2.3.6/ia64-unknown-linux-gnu/lib/gcc/ia64-unknown-linux-gnu/3.4.5/../../../../ia64-unknown-linux-gnu/bin/ld: section .data.patch [a000000000000500 -> a000000000000507] overlaps section .dynamic [a0000000000003c8 -> a000000000000507]

Cc: "Luck, Tony" <tony.luck@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 arch/ia64/kernel/gate.lds.S |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff -puN arch/ia64/kernel/gate.lds.S~ia64-increase-datapatch-offset arch/ia64/kernel/gate.lds.S
--- a/arch/ia64/kernel/gate.lds.S~ia64-increase-datapatch-offset
+++ a/arch/ia64/kernel/gate.lds.S
@@ -30,7 +30,7 @@ SECTIONS
 	 * the dynamic symbol table et al.  If this amount is insufficient,
 	 * ld -shared will barf.  Just increase it here.
 	 */
-	. = GATE_ADDR + 0x500;
+	. = GATE_ADDR + 0x600;
 
 	.data.patch		: {
 		__start_gate_mckinley_e9_patchlist = .;
_

Re: [patch 1/1] ia64: increase .data.patch offset

[Peter Chubb]

>>>>> "akpm" = akpm  <akpm@linux-foundation.org> writes:

akpm> From: Andrew Morton <akpm@linux-foundation.org> I get this:

akpm> /opt/crosstool/gcc-3.4.5-glibc-2.3.6/ia64-unknown-linux-gnu/lib/gcc/ia64-unknown-linux-gnu/3.4.5/../../../../ia64-unknown-linux-gnu/bin/ld:
akpm> section .data.patch [a000000000000500 -> a000000000000507]
akpm> overlaps section .dynamic [a0000000000003c8 -> a000000000000507]

If you switch to gcc 4.1 the patch section shrinks again and this patch
isn't necessary.

(unfortunately there're bugs in gcc 4.2 that prevent compilation of
the tiger_defconfig, or I'd be using that).

--
Dr Peter Chubb  http://www.gelato.unsw.edu.au  peterc AT gelato.unsw.edu.au
http://www.ertos.nicta.com.au           ERTOS within National ICT Australia

Re: [patch 1/1] ia64: increase .data.patch offset

[Andrew Morton]

On Wed, 14 Nov 2007 09:07:45 +1100 Peter Chubb <peterc@gelato.unsw.edu.au> wrote:

> >>>>> "akpm" = akpm  <akpm@linux-foundation.org> writes:
> 
> akpm> From: Andrew Morton <akpm@linux-foundation.org> I get this:
> 
> akpm> /opt/crosstool/gcc-3.4.5-glibc-2.3.6/ia64-unknown-linux-gnu/lib/gcc/ia64-unknown-linux-gnu/3.4.5/../../../../ia64-unknown-linux-gnu/bin/ld:
> akpm> section .data.patch [a000000000000500 -> a000000000000507]
> akpm> overlaps section .dynamic [a0000000000003c8 -> a000000000000507]
> 
> If you switch to gcc 4.1 the patch section shrinks again and this patch
> isn't necessary.

It took me two solid days work to generate my current cross-compile suite. 
Weep.

I spose I can keep this patch locally if that's the direction which i64
wants to take.  But in that case ia64 should #error out early if __GNUC__
is wrong.

Re: [patch 1/1] ia64: increase .data.patch offset

[Simon Horman]

On Tue, Nov 13, 2007 at 02:26:07PM -0800, Andrew Morton wrote:
> On Wed, 14 Nov 2007 09:07:45 +1100 Peter Chubb <peterc@gelato.unsw.edu.au> wrote:
> 
> > >>>>> "akpm" = akpm  <akpm@linux-foundation.org> writes:
> > 
> > akpm> From: Andrew Morton <akpm@linux-foundation.org> I get this:
> > 
> > akpm> /opt/crosstool/gcc-3.4.5-glibc-2.3.6/ia64-unknown-linux-gnu/lib/gcc/ia64-unknown-linux-gnu/3.4.5/../../../../ia64-unknown-linux-gnu/bin/ld:
> > akpm> section .data.patch [a000000000000500 -> a000000000000507]
> > akpm> overlaps section .dynamic [a0000000000003c8 -> a000000000000507]
> > 
> > If you switch to gcc 4.1 the patch section shrinks again and this patch
> > isn't necessary.
> 
> It took me two solid days work to generate my current cross-compile suite. 
> Weep.
> 
> I spose I can keep this patch locally if that's the direction which i64
> wants to take.  But in that case ia64 should #error out early if __GNUC__
> is wrong.

Hi Peter,

can you be a little more specific about what toolchain you are using?
I'm using crosstool but the most recent thing that it seems to like is
gcc-3.4.5 + glibc 2.3.6. I don't mind working on crosstool a bit to get
a newer gcc working, but I'd be grateful of any advice on versions to
avoid too much stabbing in the dark.

-- 
Horms, California Edition

Re: [patch 1/1] ia64: increase .data.patch offset

[Peter Chubb]

>>>>> "Simon" = Simon Horman <horms@verge.net.au> writes:

Simon> On Tue, Nov 13, 2007 at 02:26:07PM -0800, Andrew Morton wrote:
>> On Wed, 14 Nov 2007 09:07:45 +1100 Peter Chubb
>> <peterc@gelato.unsw.edu.au> wrote:
>> 
>> > >>>>> "akpm" = akpm <akpm@linux-foundation.org> writes:
>> > 
>> > akpm> From: Andrew Morton <akpm@linux-foundation.org> I get this:
>> > 
>> > akpm>
>> /opt/crosstool/gcc-3.4.5-glibc-2.3.6/ia64-unknown-linux-gnu/lib/gcc/ia64-unknown-linux-gnu/3.4.5/../../../../ia64-unknown-linux-gnu/bin/ld:
>> > akpm> section .data.patch [a000000000000500 -> a000000000000507]
>> > akpm> overlaps section .dynamic [a0000000000003c8 ->
>> a000000000000507]
>> > 
>> > If you switch to gcc 4.1 the patch section shrinks again and this
>> patch > isn't necessary.
>> 
>> It took me two solid days work to generate my current cross-compile
>> suite. Weep.
>> 
>> I spose I can keep this patch locally if that's the direction which
>> i64 wants to take.  But in that case ia64 should #error out early
>> if __GNUC__ is wrong.

Simon> Hi Peter,

Simon> can you be a little more specific about what toolchain you are
Simon> using?  I'm using crosstool but the most recent thing that it
Simon> seems to like is gcc-3.4.5 + glibc 2.3.6. I don't mind working
Simon> on crosstool a bit to get a newer gcc working, but I'd be
Simon> grateful of any advice on versions to avoid too much stabbing
Simon> in the dark.

I run the Debian packaged tools.  It's trivial then to generate cross
compilers, or native compilers.  What's more there are pre-packaged 
cross-toolchains at the emdebian site (although Itanium is a bit of an
also-ran, and at various times the prepackaged ones are inconsistent
-- for example the compiler package relies on libunwind which isn't
there, etc).

What I'll do today, is try a number of different compiler version
(it's realtively easy for me to do this), and email tomorrow which
ones compile a generic  kernel, and if I have time, which ones boot.

Currently,  I know  4.1 works (we use it for
http://www.gelato.unsw.edu.au/kerncomp ).  3.4.5 has the problem that
the patch section is too large to fit. 4.2 fails to compile
tiger_defconfig (problems with the PS2 mouse code that've already been
reported to the GCC maintainers).


--
Dr Peter Chubb  http://www.gelato.unsw.edu.au  peterc AT gelato.unsw.edu.au
http://www.ertos.nicta.com.au           ERTOS within National ICT Australia

RE: [patch 1/1] ia64: increase .data.patch offset

[Luck, Tony]

> What I'll do today, is try a number of different compiler version
> (it's realtively easy for me to do this), and email tomorrow which
> ones compile a generic  kernel, and if I have time, which ones boot.

Are some versions of the compiler actually broken (and generating spurious stuff so
overflowing this section) ... or are we just skating close to the edge so that minor
differences in generated code push us over the limit.

If the only reason to reject a compiler version can be fixed by Andrew's patch to
change the 0x500 to 0x600 in gate.lds.S, then that seems a reasonable thing
to do.

-Tony

Re: [patch 1/1] ia64: increase .data.patch offset

[Peter Chubb]

>>>>> "Tony" = Tony Luck <Luck> writes:

>> What I'll do today, is try a number of different compiler version
>> (it's realtively easy for me to do this), and email tomorrow which
>> ones compile a generic kernel, and if I have time, which ones boot.

Tony> Are some versions of the compiler actually broken (and
Tony> generating spurious stuff so overflowing this section) ... or
Tony> are we just skating close to the edge so that minor differences
Tony> in generated code push us over the limit.

Some compilers are broken.  I think 3.5.4 is OK, except it's
generating some spurious stuff.

Tony> If the only reason to reject a compiler version can be fixed by
Tony> Andrew's patch to change the 0x500 to 0x600 in gate.lds.S, then
Tony> that seems a reasonable thing to do.

I agree.
--
Dr Peter Chubb  http://www.gelato.unsw.edu.au  peterc AT gelato.unsw.edu.au
http://www.ertos.nicta.com.au           ERTOS within National ICT Australia

Re: [patch 1/1] ia64: increase .data.patch offset

[Peter Chubb]

>>>>> "Peter" = Peter Chubb <peterc@gelato.unsw.edu.au> writes:

>>>>> "Tony" = Tony Luck <Luck> writes:

>>> What I'll do today, is try a number of different compiler version
>>> (it's realtively easy for me to do this), and email tomorrow which
>>> ones compile a generic kernel, and if I have time, which ones
>>> boot.

It took me a bit longer, because all the native compilers Just Work (tm).

Tony> Are some versions of the compiler actually broken (and
Tony> generating spurious stuff so overflowing this section) ... or
Tony> are we just skating close to the edge so that minor differences
Tony> in generated code push us over the limit.

It appears that crosstool builds some buggy cross compilers.

All the native compilers work fine; I tested from 3.3 to 4.1 (4.2 and
4.3-snapshot fail to compile gensparse_defconfig and tiger_defconfig
because of bug 31490 in the GCC bugzilla).

Cross-compilers from www.emdebian.org work fine (tried 3.3, 3.4, 3.5,
4.0 and 4.1)

Cross compilers using binutils 2.15 built using crosstool fail.
Cross compilers using later binutils may work (I only tried 4.1 which
worked).

Currently there should be plenty of room in the dynamic segment.  It
starts at 0xa0...2a0 and ends at 0xa0...3E0 with all working
compilers.

Andrew, if you use Debian on your test system there's an apt-gettable
archive at http://www.emdebian.org/debian unstable containing cross
compilers, libraries etc., prebuilt for AMD64 and IA32.

Do:
	apt-get install gcc-4.1-ia64-linux-gnu
to get a compiler and all the libraries headers etc., you need.  Much
easier than crosstool.
--
Dr Peter Chubb  http://www.gelato.unsw.edu.au  peterc AT gelato.unsw.edu.au
http://www.ertos.nicta.com.au           ERTOS within National ICT Australia