Re: 2.6.23-rc8-mm1 -- powerpc link failure
On Thu, 27 Sep 2007, Andrew Morton wrote: > > +extern void arch_randomize_brk(void); > > #include "../../../fs/binfmt_elf.c" > Is this sinful extern-decl-in-C acually needed? Some time passed since I have written the patch, but I remember that this was needed, otherwise under some circumstances the build failed, but I don't remember details ... I will try to look at it more in a while. But it definitely was needed to work with that horrible include-huge-c-file-from-another-one. Thanks, -- Jiri Kosina SUSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc8-mm1 -- powerpc link failure
On Thu, 27 Sep 2007 14:13:21 +0200 (CEST)
Jiri Kosina <[EMAIL PROTECTED]> wrote:
> i386 and x86_64: randomize brk()
>
> ...
>
> --- a/arch/x86_64/ia32/ia32_binfmt.c
> +++ b/arch/x86_64/ia32/ia32_binfmt.c
> @@ -262,6 +262,7 @@ static void elf32_init(struct pt_regs *);
> #define ARCH_HAS_SETUP_ADDITIONAL_PAGES 1
> #define arch_setup_additional_pages syscall32_setup_pages
> extern int syscall32_setup_pages(struct linux_binprm *, int exstack);
> +extern void arch_randomize_brk(void);
>
> #include "../../../fs/binfmt_elf.c"
Is this sinful extern-decl-in-C acually needed?
> index b4fbe47..5a1adf9 100644
> --- a/include/asm-x86_64/elf.h
> +++ b/include/asm-x86_64/elf.h
> @@ -177,4 +177,6 @@ do if (vdso_enabled) {
> \
>
> #endif
>
> +extern void arch_randomize_brk(void);
> +
> #endif
Because we already have a declaration in the correct place?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc8-mm1 -- powerpc link failure
On Thu, Sep 27, 2007 at 10:13:42AM -0700, Andrew Morton wrote: > On Thu, 27 Sep 2007 14:13:21 +0200 (CEST) Jiri Kosina <[EMAIL PROTECTED]> > wrote: > > > On Thu, 27 Sep 2007, Andy Whitcroft wrote: > > > > > Ok, this problem seems to still persist in 2.6.23-rc8-mm2. It seems we > > > have three options from here: > > > 1) update the compiler support list to exclude these compilers, or > > > 2) back this change out, or > > > 3) switch to the version not using __weak. > > > The latter seems to be the least intrusive change. As no-one closer to > > > the problem is stepping up to make the decision I will propose we go > > > with the third option here. > > > > Andrew, > > > > if you agree with Andy that we should support compilers that don't work > > with __weak, please drop i386-and-x86_64-randomize-brk.patch and replace > > it with the one below instead (this has been already posted at > > http://lkml.org/lkml/2007/8/31/113). Thanks. > > > > We have quite a few instances of __weak in there. What is special about > this one? The bug we trigger is an ld bug - not a compiler bug. What happens is that we have the same function defined weak twice. In fs/ we include binfmt_elf.o in the build because CONFIG_BINFMT_ELF is set. And in arch/powerpc/kernel/binfmt_elf32.c: we do an: #include "../../../fs/binfmt_elf.c" Without actually trying it out I assume we trigger the ld bug because we define the same weak function twice. And this is a non-typical situation. Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc8-mm1 -- powerpc link failure
On Thu, 27 Sep 2007 14:13:21 +0200 (CEST) Jiri Kosina <[EMAIL PROTECTED]> wrote: > On Thu, 27 Sep 2007, Andy Whitcroft wrote: > > > Ok, this problem seems to still persist in 2.6.23-rc8-mm2. It seems we > > have three options from here: > > 1) update the compiler support list to exclude these compilers, or > > 2) back this change out, or > > 3) switch to the version not using __weak. > > The latter seems to be the least intrusive change. As no-one closer to > > the problem is stepping up to make the decision I will propose we go > > with the third option here. > > Andrew, > > if you agree with Andy that we should support compilers that don't work > with __weak, please drop i386-and-x86_64-randomize-brk.patch and replace > it with the one below instead (this has been already posted at > http://lkml.org/lkml/2007/8/31/113). Thanks. > We have quite a few instances of __weak in there. What is special about this one? > > From: Jiri Kosina <[EMAIL PROTECTED]> > > i386 and x86_64: randomize brk() That's a better patch anyway. We often use __weak because people can't be bothered doing all that editing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc8-mm1 -- powerpc link failure
On Thu, 27 Sep 2007, Andy Whitcroft wrote:
> Ok, this problem seems to still persist in 2.6.23-rc8-mm2. It seems we
> have three options from here:
> 1) update the compiler support list to exclude these compilers, or
> 2) back this change out, or
> 3) switch to the version not using __weak.
> The latter seems to be the least intrusive change. As no-one closer to
> the problem is stepping up to make the decision I will propose we go
> with the third option here.
Andrew,
if you agree with Andy that we should support compilers that don't work
with __weak, please drop i386-and-x86_64-randomize-brk.patch and replace
it with the one below instead (this has been already posted at
http://lkml.org/lkml/2007/8/31/113). Thanks.
From: Jiri Kosina <[EMAIL PROTECTED]>
i386 and x86_64: randomize brk()
This patch randomizes the location of the heap (brk) for i386 and x86_64.
The range is randomized in the range starting at current brk location up
to 0x0200 offset for both architectures. This, together with
pie-executable-randomization.patch and
pie-executable-randomization-fix.patch, should make the address space
randomization on i386 and x86_64 complete.
The empty stubs are not added for architectures that don't support ELF
binaries, namely blackfin, h8300, m68knommu and v850.
Arjan says:
This is known to break older versions of some emacs variants, whose dumper
code assumed that the last variable declared in the program is equal to
the start of the dynamically allocated memory region.
(The dumper is the code where emacs effectively dumps core at the end of
it's compilation stage; this coredump is then loaded as the main program
during normal use)
iirc this was 5 years or so; we found this way back when I was at RH and
we first did the security stuff there (including this brk randomization).
It wasn't all variants of emacs, and it got fixed as a result (I vaguely
remember that emacs already had code to deal with it for other archs/oses,
just ifdeffed wrongly).
It's a rare and wrong assumption as a general thing, just on x86 it mostly
happened to be true (but to be honest, it'll break too if gcc does
something fancy or if the linker does a non-standard order). Still its
something we should at least document.
Note 2: afaik it only broke the emacs *build*. I'm not 100% sure about
that (it IS 5 years ago) though.
Signed-off-by: Jiri Kosina <[EMAIL PROTECTED]>
diff --git a/arch/i386/kernel/process.c b/arch/i386/kernel/process.c
index 8466471..ba8ad15 100644
--- a/arch/i386/kernel/process.c
+++ b/arch/i386/kernel/process.c
@@ -949,3 +949,17 @@ unsigned long arch_align_stack(unsigned long sp)
sp -= get_random_int() % 8192;
return sp & ~0xf;
}
+
+void arch_randomize_brk(void)
+{
+ unsigned long new_brk;
+ unsigned long range_start;
+ unsigned long range_end;
+
+ range_start = current->mm->brk;
+ range_end = range_start + 0x0200;
+ new_brk = randomize_range(range_start, range_end, 0);
+ if (new_brk)
+ current->mm->brk = current->mm->start_brk = new_brk;
+}
+
diff --git a/arch/x86_64/ia32/ia32_binfmt.c b/arch/x86_64/ia32/ia32_binfmt.c
index dffd2ac..ccc4350 100644
--- a/arch/x86_64/ia32/ia32_binfmt.c
+++ b/arch/x86_64/ia32/ia32_binfmt.c
@@ -262,6 +262,7 @@ static void elf32_init(struct pt_regs *);
#define ARCH_HAS_SETUP_ADDITIONAL_PAGES 1
#define arch_setup_additional_pages syscall32_setup_pages
extern int syscall32_setup_pages(struct linux_binprm *, int exstack);
+extern void arch_randomize_brk(void);
#include "../../../fs/binfmt_elf.c"
diff --git a/arch/x86_64/kernel/process.c b/arch/x86_64/kernel/process.c
index 2842f50..fe7203b 100644
--- a/arch/x86_64/kernel/process.c
+++ b/arch/x86_64/kernel/process.c
@@ -902,3 +902,17 @@ unsigned long arch_align_stack(unsigned long sp)
sp -= get_random_int() % 8192;
return sp & ~0xf;
}
+
+void arch_randomize_brk(void)
+{
+ unsigned long new_brk;
+ unsigned long range_start;
+ unsigned long range_end;
+
+ range_start = current->mm->brk;
+ range_end = range_start + 0x0200;
+ new_brk = randomize_range(range_start, range_end, 0);
+ if (new_brk)
+ current->mm->brk = current->mm->start_brk = new_brk;
+}
+
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index d65f1d9..4c92461 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -1073,6 +1073,9 @@ static int load_elf_binary(struct linux_binprm *bprm,
struct pt_regs *regs)
current->mm->end_data = end_data;
current->mm->start_stack = bprm->p;
+ if (current->flags & PF_RANDOMIZE)
+ arch_randomize_brk();
+
if (current->personality & MMAP_PAGE_ZERO) {
/* Why this, you ask??? Well SVr4 maps page 0 as read-only,
and some applications "depend" upon this behavior.
diff --git a/include/asm-alpha/elf.h b/include/asm-alpha/elf.h
index 6c2d78f..18210cc
Re: 2.6.23-rc8-mm1 -- powerpc link failure
> actually, my first patch wasn't using weak symbols, but I have been > convinced that it's the way to go(tm). Please see > http://lkml.org/lkml/2007/9/1/131 and the ongoing thread. > > I am fine with replacing the brk randomization patch with the one that > wasn't using weak symbols (posted in the mentioned thread too), I have no > strong opinion either way. Ok, this problem seems to still persist in 2.6.23-rc8-mm2. It seems we have three options from here: 1) update the compiler support list to exclude these compilers, or 2) back this change out, or 3) switch to the version not using __weak. The latter seems to be the least intrusive change. As no-one closer to the problem is stepping up to make the decision I will propose we go with the third option here. -apw - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc8-mm1 -- powerpc link failure
actually, my first patch wasn't using weak symbols, but I have been convinced that it's the way to go(tm). Please see http://lkml.org/lkml/2007/9/1/131 and the ongoing thread. I am fine with replacing the brk randomization patch with the one that wasn't using weak symbols (posted in the mentioned thread too), I have no strong opinion either way. Ok, this problem seems to still persist in 2.6.23-rc8-mm2. It seems we have three options from here: 1) update the compiler support list to exclude these compilers, or 2) back this change out, or 3) switch to the version not using __weak. The latter seems to be the least intrusive change. As no-one closer to the problem is stepping up to make the decision I will propose we go with the third option here. -apw - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc8-mm1 -- powerpc link failure
On Thu, 27 Sep 2007, Andy Whitcroft wrote:
Ok, this problem seems to still persist in 2.6.23-rc8-mm2. It seems we
have three options from here:
1) update the compiler support list to exclude these compilers, or
2) back this change out, or
3) switch to the version not using __weak.
The latter seems to be the least intrusive change. As no-one closer to
the problem is stepping up to make the decision I will propose we go
with the third option here.
Andrew,
if you agree with Andy that we should support compilers that don't work
with __weak, please drop i386-and-x86_64-randomize-brk.patch and replace
it with the one below instead (this has been already posted at
http://lkml.org/lkml/2007/8/31/113). Thanks.
From: Jiri Kosina [EMAIL PROTECTED]
i386 and x86_64: randomize brk()
This patch randomizes the location of the heap (brk) for i386 and x86_64.
The range is randomized in the range starting at current brk location up
to 0x0200 offset for both architectures. This, together with
pie-executable-randomization.patch and
pie-executable-randomization-fix.patch, should make the address space
randomization on i386 and x86_64 complete.
The empty stubs are not added for architectures that don't support ELF
binaries, namely blackfin, h8300, m68knommu and v850.
Arjan says:
This is known to break older versions of some emacs variants, whose dumper
code assumed that the last variable declared in the program is equal to
the start of the dynamically allocated memory region.
(The dumper is the code where emacs effectively dumps core at the end of
it's compilation stage; this coredump is then loaded as the main program
during normal use)
iirc this was 5 years or so; we found this way back when I was at RH and
we first did the security stuff there (including this brk randomization).
It wasn't all variants of emacs, and it got fixed as a result (I vaguely
remember that emacs already had code to deal with it for other archs/oses,
just ifdeffed wrongly).
It's a rare and wrong assumption as a general thing, just on x86 it mostly
happened to be true (but to be honest, it'll break too if gcc does
something fancy or if the linker does a non-standard order). Still its
something we should at least document.
Note 2: afaik it only broke the emacs *build*. I'm not 100% sure about
that (it IS 5 years ago) though.
Signed-off-by: Jiri Kosina [EMAIL PROTECTED]
diff --git a/arch/i386/kernel/process.c b/arch/i386/kernel/process.c
index 8466471..ba8ad15 100644
--- a/arch/i386/kernel/process.c
+++ b/arch/i386/kernel/process.c
@@ -949,3 +949,17 @@ unsigned long arch_align_stack(unsigned long sp)
sp -= get_random_int() % 8192;
return sp ~0xf;
}
+
+void arch_randomize_brk(void)
+{
+ unsigned long new_brk;
+ unsigned long range_start;
+ unsigned long range_end;
+
+ range_start = current-mm-brk;
+ range_end = range_start + 0x0200;
+ new_brk = randomize_range(range_start, range_end, 0);
+ if (new_brk)
+ current-mm-brk = current-mm-start_brk = new_brk;
+}
+
diff --git a/arch/x86_64/ia32/ia32_binfmt.c b/arch/x86_64/ia32/ia32_binfmt.c
index dffd2ac..ccc4350 100644
--- a/arch/x86_64/ia32/ia32_binfmt.c
+++ b/arch/x86_64/ia32/ia32_binfmt.c
@@ -262,6 +262,7 @@ static void elf32_init(struct pt_regs *);
#define ARCH_HAS_SETUP_ADDITIONAL_PAGES 1
#define arch_setup_additional_pages syscall32_setup_pages
extern int syscall32_setup_pages(struct linux_binprm *, int exstack);
+extern void arch_randomize_brk(void);
#include ../../../fs/binfmt_elf.c
diff --git a/arch/x86_64/kernel/process.c b/arch/x86_64/kernel/process.c
index 2842f50..fe7203b 100644
--- a/arch/x86_64/kernel/process.c
+++ b/arch/x86_64/kernel/process.c
@@ -902,3 +902,17 @@ unsigned long arch_align_stack(unsigned long sp)
sp -= get_random_int() % 8192;
return sp ~0xf;
}
+
+void arch_randomize_brk(void)
+{
+ unsigned long new_brk;
+ unsigned long range_start;
+ unsigned long range_end;
+
+ range_start = current-mm-brk;
+ range_end = range_start + 0x0200;
+ new_brk = randomize_range(range_start, range_end, 0);
+ if (new_brk)
+ current-mm-brk = current-mm-start_brk = new_brk;
+}
+
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index d65f1d9..4c92461 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -1073,6 +1073,9 @@ static int load_elf_binary(struct linux_binprm *bprm,
struct pt_regs *regs)
current-mm-end_data = end_data;
current-mm-start_stack = bprm-p;
+ if (current-flags PF_RANDOMIZE)
+ arch_randomize_brk();
+
if (current-personality MMAP_PAGE_ZERO) {
/* Why this, you ask??? Well SVr4 maps page 0 as read-only,
and some applications depend upon this behavior.
diff --git a/include/asm-alpha/elf.h b/include/asm-alpha/elf.h
index 6c2d78f..18210cc 100644
--- a/include/asm-alpha/elf.h
+++
Re: 2.6.23-rc8-mm1 -- powerpc link failure
On Thu, 27 Sep 2007 14:13:21 +0200 (CEST) Jiri Kosina [EMAIL PROTECTED] wrote: On Thu, 27 Sep 2007, Andy Whitcroft wrote: Ok, this problem seems to still persist in 2.6.23-rc8-mm2. It seems we have three options from here: 1) update the compiler support list to exclude these compilers, or 2) back this change out, or 3) switch to the version not using __weak. The latter seems to be the least intrusive change. As no-one closer to the problem is stepping up to make the decision I will propose we go with the third option here. Andrew, if you agree with Andy that we should support compilers that don't work with __weak, please drop i386-and-x86_64-randomize-brk.patch and replace it with the one below instead (this has been already posted at http://lkml.org/lkml/2007/8/31/113). Thanks. We have quite a few instances of __weak in there. What is special about this one? From: Jiri Kosina [EMAIL PROTECTED] i386 and x86_64: randomize brk() That's a better patch anyway. We often use __weak because people can't be bothered doing all that editing. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc8-mm1 -- powerpc link failure
On Thu, Sep 27, 2007 at 10:13:42AM -0700, Andrew Morton wrote: On Thu, 27 Sep 2007 14:13:21 +0200 (CEST) Jiri Kosina [EMAIL PROTECTED] wrote: On Thu, 27 Sep 2007, Andy Whitcroft wrote: Ok, this problem seems to still persist in 2.6.23-rc8-mm2. It seems we have three options from here: 1) update the compiler support list to exclude these compilers, or 2) back this change out, or 3) switch to the version not using __weak. The latter seems to be the least intrusive change. As no-one closer to the problem is stepping up to make the decision I will propose we go with the third option here. Andrew, if you agree with Andy that we should support compilers that don't work with __weak, please drop i386-and-x86_64-randomize-brk.patch and replace it with the one below instead (this has been already posted at http://lkml.org/lkml/2007/8/31/113). Thanks. We have quite a few instances of __weak in there. What is special about this one? The bug we trigger is an ld bug - not a compiler bug. What happens is that we have the same function defined weak twice. In fs/ we include binfmt_elf.o in the build because CONFIG_BINFMT_ELF is set. And in arch/powerpc/kernel/binfmt_elf32.c: we do an: #include ../../../fs/binfmt_elf.c Without actually trying it out I assume we trigger the ld bug because we define the same weak function twice. And this is a non-typical situation. Sam - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc8-mm1 -- powerpc link failure
On Thu, 27 Sep 2007 14:13:21 +0200 (CEST)
Jiri Kosina [EMAIL PROTECTED] wrote:
i386 and x86_64: randomize brk()
...
--- a/arch/x86_64/ia32/ia32_binfmt.c
+++ b/arch/x86_64/ia32/ia32_binfmt.c
@@ -262,6 +262,7 @@ static void elf32_init(struct pt_regs *);
#define ARCH_HAS_SETUP_ADDITIONAL_PAGES 1
#define arch_setup_additional_pages syscall32_setup_pages
extern int syscall32_setup_pages(struct linux_binprm *, int exstack);
+extern void arch_randomize_brk(void);
#include ../../../fs/binfmt_elf.c
Is this sinful extern-decl-in-C acually needed?
index b4fbe47..5a1adf9 100644
--- a/include/asm-x86_64/elf.h
+++ b/include/asm-x86_64/elf.h
@@ -177,4 +177,6 @@ do if (vdso_enabled) {
\
#endif
+extern void arch_randomize_brk(void);
+
#endif
Because we already have a declaration in the correct place?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc8-mm1 -- powerpc link failure
On Thu, 27 Sep 2007, Andrew Morton wrote: +extern void arch_randomize_brk(void); #include ../../../fs/binfmt_elf.c Is this sinful extern-decl-in-C acually needed? Some time passed since I have written the patch, but I remember that this was needed, otherwise under some circumstances the build failed, but I don't remember details ... I will try to look at it more in a while. But it definitely was needed to work with that horrible include-huge-c-file-from-another-one. Thanks, -- Jiri Kosina SUSE Labs - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc8-mm1 -- powerpc link failure
On Tue, 25 Sep 2007, Andy Whitcroft wrote: > As suggested elsewhere I have had a go at tracking this down. Previous > problems of this kind were introduced as a result of using 'weak' > declarations to provide default implementations. This investigation led > me to the following commit: > commit c60473b5d32ea6cf4561232bc852bacd3a513528 > Author: Jiri Kosina <[EMAIL PROTECTED]> > Date: Sat Sep 15 01:49:49 2007 + > i386-and-x86_64-randomize-brk > Backing this change out seems to get us past this problem. If we are to > support compilers of this age, and I believe we currently do, then we > probabally need to avoid the weak declarations and use the Kconfig > system to provide the alternatives here. > Jiri? Hi, actually, my first patch wasn't using weak symbols, but I have been convinced that it's the way to go(tm). Please see http://lkml.org/lkml/2007/9/1/131 and the ongoing thread. I am fine with replacing the brk randomization patch with the one that wasn't using weak symbols (posted in the mentioned thread too), I have no strong opinion either way. Thanks, -- Jiri Kosina SUSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.23-rc8-mm1 -- powerpc link failure
2.6.23-rc6-mm1, 2.6.23-rc7-mm1 and 2.6.23-rc8-mm1 all fail to link correctly on a powerpc machine (elm3b19) in our test grid. It fails as below: LD vmlinux.o ld: dynreloc miscount for fs/built-in.o, section .opd ld: can not edit opd Bad value make: *** [vmlinux.o] Error 1 Compiler versions and linker versions as below: [EMAIL PROTECTED]:~/apw/linux-2.6.22# gcc -v Using built-in specs. Target: powerpc-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr --with-gxx-include-dir=/usr/include/c++/4.0.2 --enable-shared --with-system-zlib --libexecdir=/usr/lib --enable-nls --without-included-gettext --enable-threads=posix --program-suffix=-4.0 --enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk-default --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr --disable-softfloat --enable-targets=powerpc-linux,powerpc64-linux --with-cpu=default32 --disable-werror --enable-checking=release powerpc-linux-gnu Thread model: posix gcc version 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9) [EMAIL PROTECTED]:~/apw/linux-2.6.22# ld -v GNU ld version 2.16.1 Debian GNU/Linux As suggested elsewhere I have had a go at tracking this down. Previous problems of this kind were introduced as a result of using 'weak' declarations to provide default implementations. This investigation led me to the following commit: commit c60473b5d32ea6cf4561232bc852bacd3a513528 Author: Jiri Kosina <[EMAIL PROTECTED]> Date: Sat Sep 15 01:49:49 2007 + i386-and-x86_64-randomize-brk Backing this change out seems to get us past this problem. If we are to support compilers of this age, and I believe we currently do, then we probabally need to avoid the weak declarations and use the Kconfig system to provide the alternatives here. Jiri? -apw - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.23-rc8-mm1 -- powerpc link failure
2.6.23-rc6-mm1, 2.6.23-rc7-mm1 and 2.6.23-rc8-mm1 all fail to link correctly on a powerpc machine (elm3b19) in our test grid. It fails as below: LD vmlinux.o ld: dynreloc miscount for fs/built-in.o, section .opd ld: can not edit opd Bad value make: *** [vmlinux.o] Error 1 Compiler versions and linker versions as below: [EMAIL PROTECTED]:~/apw/linux-2.6.22# gcc -v Using built-in specs. Target: powerpc-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr --with-gxx-include-dir=/usr/include/c++/4.0.2 --enable-shared --with-system-zlib --libexecdir=/usr/lib --enable-nls --without-included-gettext --enable-threads=posix --program-suffix=-4.0 --enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk-default --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr --disable-softfloat --enable-targets=powerpc-linux,powerpc64-linux --with-cpu=default32 --disable-werror --enable-checking=release powerpc-linux-gnu Thread model: posix gcc version 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9) [EMAIL PROTECTED]:~/apw/linux-2.6.22# ld -v GNU ld version 2.16.1 Debian GNU/Linux As suggested elsewhere I have had a go at tracking this down. Previous problems of this kind were introduced as a result of using 'weak' declarations to provide default implementations. This investigation led me to the following commit: commit c60473b5d32ea6cf4561232bc852bacd3a513528 Author: Jiri Kosina [EMAIL PROTECTED] Date: Sat Sep 15 01:49:49 2007 + i386-and-x86_64-randomize-brk Backing this change out seems to get us past this problem. If we are to support compilers of this age, and I believe we currently do, then we probabally need to avoid the weak declarations and use the Kconfig system to provide the alternatives here. Jiri? -apw - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc8-mm1 -- powerpc link failure
On Tue, 25 Sep 2007, Andy Whitcroft wrote: As suggested elsewhere I have had a go at tracking this down. Previous problems of this kind were introduced as a result of using 'weak' declarations to provide default implementations. This investigation led me to the following commit: commit c60473b5d32ea6cf4561232bc852bacd3a513528 Author: Jiri Kosina [EMAIL PROTECTED] Date: Sat Sep 15 01:49:49 2007 + i386-and-x86_64-randomize-brk Backing this change out seems to get us past this problem. If we are to support compilers of this age, and I believe we currently do, then we probabally need to avoid the weak declarations and use the Kconfig system to provide the alternatives here. Jiri? Hi, actually, my first patch wasn't using weak symbols, but I have been convinced that it's the way to go(tm). Please see http://lkml.org/lkml/2007/9/1/131 and the ongoing thread. I am fine with replacing the brk randomization patch with the one that wasn't using weak symbols (posted in the mentioned thread too), I have no strong opinion either way. Thanks, -- Jiri Kosina SUSE Labs - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
