(CC'ing lkml)
On Sun, 26 Sep 2004, Jochen Friedrich wrote:
> > Or maybe it is the binutils? After downgrading to 2.14 from a previous
> > toolchain source, I could build linux-2.6.8 with gcc-3.4.
>
> I'm using binutils 2.15 and gcc 3.4.2 on Alpha to cross compile 2.6. All i
> noticed is that the compiler optimizes sprintf(x,"%s",y) to strcpy(x,y)
> which then fails to link or causes unresolved externals because strcpy is
> an inline function on m68k. The fix is to do the replacement in the
> source, like here:
I remember seeing a similar discussion on lkml about some other automatic
replacements a while ago, but I cannot remember the details...
Is this the correct(TM) way to fix this issue, or is there a better solution?
> diff -c -r1.1.1.21 binfmt_misc.c
> *** fs/binfmt_misc.c 15 Aug 2004 14:18:10 -0000 1.1.1.21
> --- fs/binfmt_misc.c 26 Sep 2004 18:54:27 -0000
> ***************
> *** 461,467 ****
> dp = page + strlen(page);
>
> /* print the special flags */
> ! sprintf (dp, "%s", flags);
> dp += strlen (flags);
> if (e->flags & MISC_FMT_PRESERVE_ARGV0) {
> *dp ++ = 'P';
> --- 461,467 ----
> dp = page + strlen(page);
>
> /* print the special flags */
> ! strcpy (dp, flags);
> dp += strlen (flags);
> if (e->flags & MISC_FMT_PRESERVE_ARGV0) {
> *dp ++ = 'P';
>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Mon, 2004-09-27 at 13:17 +0200, Geert Uytterhoeven wrote:
> (CC'ing lkml)
>
> On Sun, 26 Sep 2004, Jochen Friedrich wrote:
> > > Or maybe it is the binutils? After downgrading to 2.14 from a previous
> > > toolchain source, I could build linux-2.6.8 with gcc-3.4.
> >
> > I'm using binutils 2.15 and gcc 3.4.2 on Alpha to cross compile 2.6. All i
> > noticed is that the compiler optimizes sprintf(x,"%s",y) to strcpy(x,y)
> > which then fails to link or causes unresolved externals because strcpy is
> > an inline function on m68k. The fix is to do the replacement in the
> > source, like here:
>
> I remember seeing a similar discussion on lkml about some other automatic
> replacements a while ago, but I cannot remember the details...
Do you mean the strncpy() -> strlcpy() conversion which leads to
information leaks from kernel to user-space im several cases (and Alan
cox fixed the wrong replacements in the netword drivers IIRC).
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
On Mon, 27 Sep 2004, Bernd Petrovitsch wrote:
> On Mon, 2004-09-27 at 13:17 +0200, Geert Uytterhoeven wrote:
> > (CC'ing lkml)
> >
> > On Sun, 26 Sep 2004, Jochen Friedrich wrote:
> > > > Or maybe it is the binutils? After downgrading to 2.14 from a previous
> > > > toolchain source, I could build linux-2.6.8 with gcc-3.4.
> > >
> > > I'm using binutils 2.15 and gcc 3.4.2 on Alpha to cross compile 2.6. All i
> > > noticed is that the compiler optimizes sprintf(x,"%s",y) to strcpy(x,y)
> > > which then fails to link or causes unresolved externals because strcpy is
> > > an inline function on m68k. The fix is to do the replacement in the
> > > source, like here:
> >
> > I remember seeing a similar discussion on lkml about some other automatic
> > replacements a while ago, but I cannot remember the details...
>
> Do you mean the strncpy() -> strlcpy() conversion which leads to
> information leaks from kernel to user-space im several cases (and Alan
> cox fixed the wrong replacements in the netword drivers IIRC).
No, that was a manual conversion.
IIRC, it was about gcc replacing strcpy() by memcpy() if the string was
constant, or something like that. And it broke the PPC boot code due to the
RELOC()s.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds