Ubuntu
gcc-4.0 package

current gcc-4.0 is utterly useless on m68k

Bug #21458 reported by Debian Bug Importer
6
Affects Status Importance Assigned to Milestone
gcc-4.0 (Debian)
Fix Released
Unknown
gcc-4.0 (Ubuntu)
Invalid
High
Matthias Klose

Bug Description

Automatically imported from Debian bug report #327780 http://bugs.debian.org/327780

See original description
Revision history for this message
In , Wouter Verhelst (wouter-debian) wrote : Too hasty

reassign 327780 binutils
found 327780 2.16.1cvs20050902-1
thanks

Sorry, I was a bit too hasty.

Current gcc is quite some time in the archive already, so it's unlikely
it's at fault. Binutils, OTOH, has seen a recent upload. Downgrading it
to the previous version indeed fixes the segfault issues.

--
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond

Revision history for this message
In , Matthias Klose (doko-cs) wrote : Re: Bug#327780: current gcc-4.0 is utterly useless on m68k

reassign 327780 m68k
thanks

that's unreproducible on crest/sid, although I can reproduce it on
another machine with the very same versions of gcc-4.0 and libc6. So
why not file it for libc6?

The point of reassigning the report to an unknown package is to ask,
if it's time to drop m68k from the release architectures or just set
the severity of all m68k reports to wishlist. There's currently nobody
interested in forwarding m68k related bug reports upstream and testing
m68k compiler versions. There are at least six more unhandled m68k
reports.

My email from July (http://lists.debian.org/debian-release/2005/07/msg00069.html)
is left unanswered, so I have to assume, that m68k isn't supported
anymore and will start to downgrade all m68k related reports to a
non-RC severity.

  Matthias

Wouter Verhelst writes:
> Package: gcc-4.0
> Version: 4.0.1-6
> Severity: grave
> Justification: renders package unusable
>
> Hi,
>
> Script started on Mon Sep 12 08:22:21 2005
> wouter@ska: /home/wouter~$ cat >foo.c
> int main() {
> ;
> return 0;
> }
> wouter@ska:~$ gcc -o foo foo.c
> wouter@ska:~$ ./foo
> Segmentation fault
> wouter@ska:~$
>
> Since this is exactly what configure-scripts try to compile to see
> whether the C compiler works, nothing will compile on m68k anymore.
>
> -- System Information:
> Debian Release: testing/unstable
> APT prefers unstable
> APT policy: (500, 'unstable'), (500, 'testing')
> Architecture: m68k
> Shell: /bin/sh linked to /bin/bash
> Kernel: Linux 2.4.27-mvme16x
> Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
>
> Versions of packages gcc-4.0 depends on:
> ii binutils 2.16.1cvs20050902-1 The GNU assembler, linker and bina
> ii cpp-4.0 4.0.1-6 The GNU C preprocessor
> ii gcc-4.0-base 4.0.1-6 The GNU Compiler Collection (base
> ii libc6 2.3.5-6 GNU C Library: Shared libraries an
> ii libgcc2 4.0.1-6 GCC support library
>
> Versions of packages gcc-4.0 recommends:
> ii libc6-dev 2.3.5-6 GNU C Library: Development Librari
> pn libmudflap0-dev <none> (no description available)
>
> -- no debconf information
>
>
> --
> To UNSUBSCRIBE, email to <email address hidden>
> with a subject of "unsubscribe". Trouble? Contact <email address hidden>

Revision history for this message
In , Matthias Klose (doko-cs) wrote : Re: Bug#327780: Too hasty

reassign 327780 binutils
thanks

anyway, the question for m68k support is still valid.

Wouter Verhelst writes:
> reassign 327780 binutils
> found 327780 2.16.1cvs20050902-1
> thanks
>
> Sorry, I was a bit too hasty.
>
> Current gcc is quite some time in the archive already, so it's unlikely
> it's at fault. Binutils, OTOH, has seen a recent upload. Downgrading it
> to the previous version indeed fixes the segfault issues.

Revision history for this message
In , Steve Langasek (vorlon) wrote : reassign 327780 to binutils

# Automatically generated email from bts, devscripts version 2.9.5
reassign 327780 binutils 2.16.1cvs20050902-1

Revision history for this message
In , Ingo Juergensmann (ij-2005) wrote : Re: Bug#327780: current gcc-4.0 is utterly useless on m68k

On Mon, Sep 12, 2005 at 09:28:30AM +0200, Matthias Klose wrote:

> that's unreproducible on crest/sid, although I can reproduce it on
> another machine with the very same versions of gcc-4.0 and libc6. So
> why not file it for libc6?

What cpu type is that other machine? I assume that ska is a 040?

> The point of reassigning the report to an unknown package is to ask,
> if it's time to drop m68k from the release architectures or just set
> the severity of all m68k reports to wishlist. There's currently nobody
> interested in forwarding m68k related bug reports upstream and testing
> m68k compiler versions. There are at least six more unhandled m68k
> reports.
> My email from July (http://lists.debian.org/debian-release/2005/07/msg00069.html)
> is left unanswered, so I have to assume, that m68k isn't supported
> anymore and will start to downgrade all m68k related reports to a
> non-RC severity.

Uhm? Unanswered? I thought Wouter and Adam step up to fill the gap?

--
Ciao... // Fon: 0381-2744150
      Ingo \X/ SIP: <email address hidden>

gpg pubkey: http://www.juergensmann.de/ij/public_key.asc

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Automatically imported from Debian bug report #327780 http://bugs.debian.org/327780

Revision history for this message
Matthias Klose (doko) wrote :

m68k only

Revision history for this message
In , Wouter Verhelst (wouter-debian) wrote : retitle 327780 to current binutils are utterly useless on m68k

# Automatically generated email from bts, devscripts version 2.9.7
retitle 327780 current binutils are utterly useless on m68k

Revision history for this message
In , Wouter Verhelst (wouter-debian) wrote : submitter 327780

# Automatically generated email from bts, devscripts version 2.8.14
submitter 327780 Wouter Verhelst <email address hidden>

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-Id: <email address hidden>
Date: Mon, 12 Sep 2005 08:33:47 +0200
From: Wouter Verhelst <wouter@ska>
To: Debian Bug Tracking System <email address hidden>
Subject: current gcc-4.0 is utterly useless on m68k

Package: gcc-4.0
Version: 4.0.1-6
Severity: grave
Justification: renders package unusable

Hi,

Script started on Mon Sep 12 08:22:21 2005
wouter@ska: /home/wouter~$ cat >foo.c
int main() {
;
return 0;
}
wouter@ska:~$ gcc -o foo foo.c
wouter@ska:~$ ./foo
Segmentation fault
wouter@ska:~$

Since this is exactly what configure-scripts try to compile to see
whether the C compiler works, nothing will compile on m68k anymore.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: m68k
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.4.27-mvme16x
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages gcc-4.0 depends on:
ii binutils 2.16.1cvs20050902-1 The GNU assembler, linker and bina
ii cpp-4.0 4.0.1-6 The GNU C preprocessor
ii gcc-4.0-base 4.0.1-6 The GNU Compiler Collection (base
ii libc6 2.3.5-6 GNU C Library: Shared libraries an
ii libgcc2 4.0.1-6 GCC support library

Versions of packages gcc-4.0 recommends:
ii libc6-dev 2.3.5-6 GNU C Library: Development Librari
pn libmudflap0-dev <none> (no description available)

-- no debconf information

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Mon, 12 Sep 2005 09:06:16 +0200
From: Wouter Verhelst <email address hidden>
To: <email address hidden>
Cc: <email address hidden>
Subject: Too hasty

reassign 327780 binutils
found 327780 2.16.1cvs20050902-1
thanks

Sorry, I was a bit too hasty.

Current gcc is quite some time in the archive already, so it's unlikely
it's at fault. Binutils, OTOH, has seen a recent upload. Downgrading it
to the previous version indeed fixes the segfault issues.

--
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Mon, 12 Sep 2005 09:28:30 +0200
From: Matthias Klose <email address hidden>
To: Wouter Verhelst <email address hidden>, <email address hidden>
Cc: <email address hidden>, <email address hidden>,
        <email address hidden>
Subject: Re: Bug#327780: current gcc-4.0 is utterly useless on m68k

reassign 327780 m68k
thanks

that's unreproducible on crest/sid, although I can reproduce it on
another machine with the very same versions of gcc-4.0 and libc6. So
why not file it for libc6?

The point of reassigning the report to an unknown package is to ask,
if it's time to drop m68k from the release architectures or just set
the severity of all m68k reports to wishlist. There's currently nobody
interested in forwarding m68k related bug reports upstream and testing
m68k compiler versions. There are at least six more unhandled m68k
reports.

My email from July (http://lists.debian.org/debian-release/2005/07/msg00069.html)
is left unanswered, so I have to assume, that m68k isn't supported
anymore and will start to downgrade all m68k related reports to a
non-RC severity.

  Matthias

Wouter Verhelst writes:
> Package: gcc-4.0
> Version: 4.0.1-6
> Severity: grave
> Justification: renders package unusable
>
> Hi,
>
> Script started on Mon Sep 12 08:22:21 2005
> wouter@ska: /home/wouter~$ cat >foo.c
> int main() {
> ;
> return 0;
> }
> wouter@ska:~$ gcc -o foo foo.c
> wouter@ska:~$ ./foo
> Segmentation fault
> wouter@ska:~$
>
> Since this is exactly what configure-scripts try to compile to see
> whether the C compiler works, nothing will compile on m68k anymore.
>
> -- System Information:
> Debian Release: testing/unstable
> APT prefers unstable
> APT policy: (500, 'unstable'), (500, 'testing')
> Architecture: m68k
> Shell: /bin/sh linked to /bin/bash
> Kernel: Linux 2.4.27-mvme16x
> Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
>
> Versions of packages gcc-4.0 depends on:
> ii binutils 2.16.1cvs20050902-1 The GNU assembler, linker and bina
> ii cpp-4.0 4.0.1-6 The GNU C preprocessor
> ii gcc-4.0-base 4.0.1-6 The GNU Compiler Collection (base
> ii libc6 2.3.5-6 GNU C Library: Shared libraries an
> ii libgcc2 4.0.1-6 GCC support library
>
> Versions of packages gcc-4.0 recommends:
> ii libc6-dev 2.3.5-6 GNU C Library: Development Librari
> pn libmudflap0-dev <none> (no description available)
>
> -- no debconf information
>
>
> --
> To UNSUBSCRIBE, email to <email address hidden>
> with a subject of "unsubscribe". Trouble? Contact <email address hidden>

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Mon, 12 Sep 2005 09:36:22 +0200
From: Matthias Klose <email address hidden>
To: Wouter Verhelst <email address hidden>, <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#327780: Too hasty

reassign 327780 binutils
thanks

anyway, the question for m68k support is still valid.

Wouter Verhelst writes:
> reassign 327780 binutils
> found 327780 2.16.1cvs20050902-1
> thanks
>
> Sorry, I was a bit too hasty.
>
> Current gcc is quite some time in the archive already, so it's unlikely
> it's at fault. Binutils, OTOH, has seen a recent upload. Downgrading it
> to the previous version indeed fixes the segfault issues.

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-Id: <email address hidden>
Date: Mon, 12 Sep 2005 00:45:01 -0700
From: Steve Langasek <email address hidden>
To: <email address hidden>
Subject: reassign 327780 to binutils

# Automatically generated email from bts, devscripts version 2.9.5
reassign 327780 binutils 2.16.1cvs20050902-1

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <20050912075906.GF6149@2004.bluespice.org>
Date: Mon, 12 Sep 2005 09:59:06 +0200
From: Ingo Juergensmann <ij@2005.bluespice.org>
To: Matthias Klose <email address hidden>
Cc: Wouter Verhelst <email address hidden>, <email address hidden>,
 <email address hidden>, <email address hidden>, <email address hidden>
Subject: Re: Bug#327780: current gcc-4.0 is utterly useless on m68k

--4VrXvz3cwkc87Wze
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Sep 12, 2005 at 09:28:30AM +0200, Matthias Klose wrote:

> that's unreproducible on crest/sid, although I can reproduce it on
> another machine with the very same versions of gcc-4.0 and libc6. So
> why not file it for libc6?

What cpu type is that other machine? I assume that ska is a 040?
=20
> The point of reassigning the report to an unknown package is to ask,
> if it's time to drop m68k from the release architectures or just set
> the severity of all m68k reports to wishlist. There's currently nobody
> interested in forwarding m68k related bug reports upstream and testing
> m68k compiler versions. There are at least six more unhandled m68k
> reports.
> My email from July (http://lists.debian.org/debian-release/2005/07/msg000=
 69.html)
> is left unanswered, so I have to assume, that m68k isn't supported
> anymore and will start to downgrade all m68k related reports to a
> non-RC severity.

Uhm? Unanswered? I thought Wouter and Adam step up to fill the gap?

--=20
Ciao... // Fon: 0381-2744150=20
      Ingo \X/ SIP: <email address hidden>

gpg pubkey: http://www.juergensmann.de/ij/public_key.asc

--4VrXvz3cwkc87Wze
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDJTVKlCnCZmI+zY0RArAaAKCx3cr9LWKdrVvauYt0BlQxRD1qNQCfX3eq
geJEg/uNgf1wkq+Ke5ump6Q=
=7nHw
-----END PGP SIGNATURE-----

--4VrXvz3cwkc87Wze--

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-Id: <email address hidden>
Date: Fri, 16 Sep 2005 12:47:05 +0200
From: Wouter Verhelst <email address hidden>
To: <email address hidden>
Subject: retitle 327780 to current binutils are utterly useless on m68k

# Automatically generated email from bts, devscripts version 2.9.7
retitle 327780 current binutils are utterly useless on m68k

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-Id: <email address hidden>
Date: Fri, 16 Sep 2005 15:15:46 +0200
From: Wouter Verhelst <email address hidden>
To: <email address hidden>
Subject: submitter 327780

# Automatically generated email from bts, devscripts version 2.8.14
submitter 327780 Wouter Verhelst <email address hidden>

Revision history for this message
In , Wouter Verhelst (wouter) wrote : Some info

To at least give someone a start to track down this bug...

I played a bit with objdump today, trying to find out what the hell is
going wrong.

According to gdb, this is what happens when I try to run an application
compiled with the broken binutils:

#0 0x800002e0 in ?? ()
(gdb)

I then did 'objdump -D <binary>', and got the following at that
address (section <.plt>):

800002e0: 4efb 0171 8000 jmp %pc@(28b6 <_init-0x7fffd9fa>)@(0000000000000000)
800002e6: 25d4

whereas the exact same source compiled with working binutils produces
this (different address, but it's also the sixth instruction in the
<.plt> section):

80000380: 4efb 0171 0000 jmp %pc@(8000267c <_GLOBAL_OFFSET_TABLE_+0xc>)@(0000000000000000)
80000386: 22fa

I think it's clear that the first is totally wrong in that it tries to
jump to an address outside the code section.

If required, I can send the binaries (both the broken and the working
one) and a core file. I'll try to further identify the bug myself, but I
don't know much about binutils' internals or the ELF file format, so
don't expect much luck...

--
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Mon, 31 Oct 2005 15:34:38 +0100
From: Wouter Verhelst <email address hidden>
To: <email address hidden>
Subject: Some info

To at least give someone a start to track down this bug...

I played a bit with objdump today, trying to find out what the hell is
going wrong.

According to gdb, this is what happens when I try to run an application
compiled with the broken binutils:

#0 0x800002e0 in ?? ()
(gdb)

I then did 'objdump -D <binary>', and got the following at that
address (section <.plt>):

800002e0: 4efb 0171 8000 jmp %pc@(28b6 <_init-0x7fffd9fa>)@(0000000000000000)
800002e6: 25d4

whereas the exact same source compiled with working binutils produces
this (different address, but it's also the sixth instruction in the
<.plt> section):

80000380: 4efb 0171 0000 jmp %pc@(8000267c <_GLOBAL_OFFSET_TABLE_+0xc>)@(0000000000000000)
80000386: 22fa

I think it's clear that the first is totally wrong in that it tries to
jump to an address outside the code section.

If required, I can send the binaries (both the broken and the working
one) and a core file. I'll try to further identify the bug myself, but I
don't know much about binutils' internals or the ELF file format, so
don't expect much luck...

--
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond

Revision history for this message
In , Nathanael Nerode (neroden-twcny) wrote : Upstream bugzilla

Has anyone considered, wild though this may sound, forwarding this to upstream
Bugzilla? http://www.sourceware.org/bugzilla/.

There's not a single m68k bug in upstream's Bugzilla, yet m68k bugs keep being
reported to Debian.

--
Nathanael Nerode <email address hidden>

[Insert famous quote here]

Revision history for this message
In , Wouter Verhelst (wouter) wrote : Cause
Download full text (7.0 KiB)

tags 327780 + patch
thanks

Hi,

With a little help from my friends (on IRC)...

I've identified the cause of this bug to be part of revision 1.74 of
bfd/elf32-m68k.c in the binutils source. I confirmed that it works by
producing a cross-binutils on my (powerpc) laptop from the binutils
source package with only that revision reversed.

I'm building a native binutils right now to verify, but I don't expect
any problems there.

The patch that I applied follows. Note that this completely removes the
PLT support for the ColdFire V4E (i.e., it's a verbatim reversion of
revision 1.74), so it's not really suitable for upstream; but since
Debian doesn't support the V4E (yet), this should do for the moment --
unless someone identifies the bug Real Soon and fixes it :-)

--- elf32-m68k.c.orig 2005-08-31 05:27:29.000000000 +0200
+++ elf32-m68k.c 2005-10-31 20:25:40.000000000 +0100
@@ -217,37 +217,6 @@
   0, 0, 0, 0 /* replaced with offset to start of .plt. */
 };

-
-#define CFV4E_PLT_ENTRY_SIZE 24
-
-#define CFV4E_FLAG(abfd) (elf_elfheader (abfd)->e_flags & EF_CFV4E)
-
-static const bfd_byte elf_cfv4e_plt0_entry[CFV4E_PLT_ENTRY_SIZE] =
-{
- 0x20, 0x3c,
- 0, 0, 0, 0, /* Replaced with offset to .got + 4. */
- 0x2f, 0x3b, 0x08, 0xfa, /* move.l (%pc,addr),-(%sp) */
- 0x20, 0x3c,
- 0, 0, 0, 0, /* Replaced with offset to .got + 8. */
- 0x20, 0x7b, 0x08, 0x00, /* move.l (%pc,%d0:l), %a0 */
- 0x4e, 0xd0, /* jmp (%a0) */
- 0x4e, 0x71 /* nop */
-};
-
-/* Subsequent entries in a procedure linkage table look like this. */
-
-static const bfd_byte elf_cfv4e_plt_entry[CFV4E_PLT_ENTRY_SIZE] =
-{
- 0x20, 0x3c,
- 0, 0, 0, 0, /* Replaced with offset to symbol's .got entry. */
- 0x20, 0x7b, 0x08, 0x00, /* move.l (%pc,%d0:l), %a0 */
- 0x4e, 0xd0, /* jmp (%a0) */
- 0x2f, 0x3c, /* move.l #offset,-(%sp) */
- 0, 0, 0, 0, /* Replaced with offset into relocation table. */
- 0x60, 0xff, /* bra.l .plt */
- 0, 0, 0, 0 /* Replaced with offset to start of .plt. */
-};
-
 #define CPU32_FLAG(abfd) (elf_elfheader (abfd)->e_flags & EF_CPU32)

 #define PLT_CPU32_ENTRY_SIZE 24
@@ -1013,8 +982,6 @@
  {
    if (CPU32_FLAG (dynobj))
      s->size += PLT_CPU32_ENTRY_SIZE;
- else if (CFV4E_FLAG (dynobj))
- s->size += CFV4E_PLT_ENTRY_SIZE;
    else
      s->size += PLT_ENTRY_SIZE;
  }
@@ -1036,8 +1003,6 @@
       /* Make room for this entry. */
       if (CPU32_FLAG (dynobj))
         s->size += PLT_CPU32_ENTRY_SIZE;
- else if (CFV4E_FLAG (dynobj))
- s->size += CFV4E_PLT_ENTRY_SIZE;
       else
         s->size += PLT_ENTRY_SIZE;

@@ -1823,19 +1788,17 @@
   corresponds to this symbol. This is the index of this symbol
   in all the symbols for which we are making plt entries. The
   first entry in the procedure linkage table is reserved. */
- if (CPU32_FLAG (output_bfd))
- plt_index = (h->plt.offset / PLT_CPU32_ENTRY_SIZE) - 1;
- else if (CFV4E_FLAG (output_bfd))
- plt_index = (h->plt.offset / CFV4E_PLT_ENTRY_SIZE) - 1;
+ if ( CPU32_FLAG (output_bfd))
+ plt_index = h->plt.offset / PLT_CPU32_ENTRY_SIZE - 1;
    ...

Read more...

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-Id: <email address hidden>
Date: Mon, 31 Oct 2005 13:52:37 -0500
From: Nathanael Nerode <email address hidden>
To: <email address hidden>
Subject: Upstream bugzilla

Has anyone considered, wild though this may sound, forwarding this to upstream
Bugzilla? http://www.sourceware.org/bugzilla/.

There's not a single m68k bug in upstream's Bugzilla, yet m68k bugs keep being
reported to Debian.

--
Nathanael Nerode <email address hidden>

[Insert famous quote here]

Revision history for this message
Debian Bug Importer (debzilla) wrote :
Download full text (7.2 KiB)

Message-ID: <email address hidden>
Date: Mon, 31 Oct 2005 20:30:32 +0100
From: Wouter Verhelst <email address hidden>
To: <email address hidden>, <email address hidden>
Subject: Cause

tags 327780 + patch
thanks

Hi,

With a little help from my friends (on IRC)...

I've identified the cause of this bug to be part of revision 1.74 of
bfd/elf32-m68k.c in the binutils source. I confirmed that it works by
producing a cross-binutils on my (powerpc) laptop from the binutils
source package with only that revision reversed.

I'm building a native binutils right now to verify, but I don't expect
any problems there.

The patch that I applied follows. Note that this completely removes the
PLT support for the ColdFire V4E (i.e., it's a verbatim reversion of
revision 1.74), so it's not really suitable for upstream; but since
Debian doesn't support the V4E (yet), this should do for the moment --
unless someone identifies the bug Real Soon and fixes it :-)

--- elf32-m68k.c.orig 2005-08-31 05:27:29.000000000 +0200
+++ elf32-m68k.c 2005-10-31 20:25:40.000000000 +0100
@@ -217,37 +217,6 @@
   0, 0, 0, 0 /* replaced with offset to start of .plt. */
 };

-
-#define CFV4E_PLT_ENTRY_SIZE 24
-
-#define CFV4E_FLAG(abfd) (elf_elfheader (abfd)->e_flags & EF_CFV4E)
-
-static const bfd_byte elf_cfv4e_plt0_entry[CFV4E_PLT_ENTRY_SIZE] =
-{
- 0x20, 0x3c,
- 0, 0, 0, 0, /* Replaced with offset to .got + 4. */
- 0x2f, 0x3b, 0x08, 0xfa, /* move.l (%pc,addr),-(%sp) */
- 0x20, 0x3c,
- 0, 0, 0, 0, /* Replaced with offset to .got + 8. */
- 0x20, 0x7b, 0x08, 0x00, /* move.l (%pc,%d0:l), %a0 */
- 0x4e, 0xd0, /* jmp (%a0) */
- 0x4e, 0x71 /* nop */
-};
-
-/* Subsequent entries in a procedure linkage table look like this. */
-
-static const bfd_byte elf_cfv4e_plt_entry[CFV4E_PLT_ENTRY_SIZE] =
-{
- 0x20, 0x3c,
- 0, 0, 0, 0, /* Replaced with offset to symbol's .got entry. */
- 0x20, 0x7b, 0x08, 0x00, /* move.l (%pc,%d0:l), %a0 */
- 0x4e, 0xd0, /* jmp (%a0) */
- 0x2f, 0x3c, /* move.l #offset,-(%sp) */
- 0, 0, 0, 0, /* Replaced with offset into relocation table. */
- 0x60, 0xff, /* bra.l .plt */
- 0, 0, 0, 0 /* Replaced with offset to start of .plt. */
-};
-
 #define CPU32_FLAG(abfd) (elf_elfheader (abfd)->e_flags & EF_CPU32)

 #define PLT_CPU32_ENTRY_SIZE 24
@@ -1013,8 +982,6 @@
  {
    if (CPU32_FLAG (dynobj))
      s->size += PLT_CPU32_ENTRY_SIZE;
- else if (CFV4E_FLAG (dynobj))
- s->size += CFV4E_PLT_ENTRY_SIZE;
    else
      s->size += PLT_ENTRY_SIZE;
  }
@@ -1036,8 +1003,6 @@
       /* Make room for this entry. */
       if (CPU32_FLAG (dynobj))
         s->size += PLT_CPU32_ENTRY_SIZE;
- else if (CFV4E_FLAG (dynobj))
- s->size += CFV4E_PLT_ENTRY_SIZE;
       else
         s->size += PLT_ENTRY_SIZE;

@@ -1823,19 +1788,17 @@
   corresponds to this symbol. This is the index of this symbol
   in all the symbols for which we are making plt entries. The
   first entry in the procedure linkage table is reserved. */
- if (CPU32_FLAG (output_bfd))
- plt_index = (h->plt.offset / PLT_CPU32_ENTRY_SIZE) - 1;
- ...

Read more...

Revision history for this message
In , Wouter Verhelst (wouter) wrote : mark 327780 forwarded

package binutils
forwarded 327780 http://sourceware.org/bugzilla/show_bug.cgi?id=1775
thanks

--
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Tue, 1 Nov 2005 15:15:53 +0100
From: Wouter Verhelst <email address hidden>
To: <email address hidden>
Subject: mark 327780 forwarded

package binutils
forwarded 327780 http://sourceware.org/bugzilla/show_bug.cgi?id=1775
thanks

--
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond

Revision history for this message
In , Wouter Verhelst (wouter) wrote : [amodra@bigpond.net.au: Re: [Bug ld/1775] New: Invalid code in PLT section]

Seems there's a fix already...

----- Forwarded message from Alan Modra <email address hidden> -----

Date: Wed, 2 Nov 2005 09:25:55 +1030
From: Alan Modra <email address hidden>
To: <email address hidden>
Cc: <email address hidden>
Subject: Re: [Bug ld/1775] New: Invalid code in PLT section
Message-ID: <email address hidden>
In-Reply-To: <email address hidden>
User-Agent: Mutt/1.4i
X-Spam-Level:
X-Spam-Status: No, score=0.3 required=4.0 tests=BAYES_00,SUBJECT_DRUG_GAP_VIC
 autolearn=no version=3.0.3

On Tue, Nov 01, 2005 at 02:14:45PM -0000, wouter at grep dot be wrote:
> As discussed in Debian bug#327780 (http://bugs.debian.org/327780), binutils are
> currently broken on m68k. The culprit seems to be revision 1.74 of
> src/elf32-m68k.c, which adds ColdFire V4E PLT support but somehow breaks
> "regular" m68k PLT support in doing so.

A quick glance over the rev 1.74 patch shows up the following lack of
parentheses.

 * elf32-m68k.c (elf_m68k_finish_dynamic_symbol): Add required
 parentheses.

Index: bfd/elf32-m68k.c
===================================================================
RCS file: /cvs/src/src/bfd/elf32-m68k.c,v
retrieving revision 1.83
diff -u -p -r1.83 elf32-m68k.c
--- bfd/elf32-m68k.c 6 Oct 2005 19:21:14 -0000 1.83
+++ bfd/elf32-m68k.c 1 Nov 2005 22:52:20 -0000
@@ -1871,7 +1871,7 @@ elf_m68k_finish_dynamic_symbol (output_b
     + got_offset
     - (splt->output_section->vma
        + h->plt.offset
- + CFV4E_FLAG (output_bfd) ? 8 : 2),
+ + (CFV4E_FLAG (output_bfd) ? 8 : 2)),
     splt->contents + h->plt.offset + plt_off1);

       bfd_put_32 (output_bfd, plt_index * sizeof (Elf32_External_Rela),
@@ -1884,7 +1884,7 @@ elf_m68k_finish_dynamic_symbol (output_b
     (splt->output_section->vma
      + splt->output_offset
      + h->plt.offset
- + CFV4E_FLAG (output_bfd) ? 12 : 8),
+ + (CFV4E_FLAG (output_bfd) ? 12 : 8)),
     sgot->contents + got_offset);

       /* Fill in the entry in the .rela.plt section. */

--
Alan Modra
IBM OzLabs - Linux Technology Centre

----- End forwarded message -----

--
.../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/
./ --/ ./ / .--/ ../ -/ ..../ / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/
-.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ /
./ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ ..../ -./ ---/ .-../
---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Wed, 2 Nov 2005 07:43:41 +0100
From: Wouter Verhelst <email address hidden>
To: <email address hidden>
Subject: [<email address hidden>: Re: [Bug ld/1775] New: Invalid code in PLT section]

Seems there's a fix already...

----- Forwarded message from Alan Modra <email address hidden> -----

Date: Wed, 2 Nov 2005 09:25:55 +1030
From: Alan Modra <email address hidden>
To: <email address hidden>
Cc: <email address hidden>
Subject: Re: [Bug ld/1775] New: Invalid code in PLT section
Message-ID: <email address hidden>
In-Reply-To: <email address hidden>
User-Agent: Mutt/1.4i
X-Spam-Level:
X-Spam-Status: No, score=0.3 required=4.0 tests=BAYES_00,SUBJECT_DRUG_GAP_VIC
 autolearn=no version=3.0.3

On Tue, Nov 01, 2005 at 02:14:45PM -0000, wouter at grep dot be wrote:
> As discussed in Debian bug#327780 (http://bugs.debian.org/327780), binutils are
> currently broken on m68k. The culprit seems to be revision 1.74 of
> src/elf32-m68k.c, which adds ColdFire V4E PLT support but somehow breaks
> "regular" m68k PLT support in doing so.

A quick glance over the rev 1.74 patch shows up the following lack of
parentheses.

 * elf32-m68k.c (elf_m68k_finish_dynamic_symbol): Add required
 parentheses.

Index: bfd/elf32-m68k.c
===================================================================
RCS file: /cvs/src/src/bfd/elf32-m68k.c,v
retrieving revision 1.83
diff -u -p -r1.83 elf32-m68k.c
--- bfd/elf32-m68k.c 6 Oct 2005 19:21:14 -0000 1.83
+++ bfd/elf32-m68k.c 1 Nov 2005 22:52:20 -0000
@@ -1871,7 +1871,7 @@ elf_m68k_finish_dynamic_symbol (output_b
     + got_offset
     - (splt->output_section->vma
        + h->plt.offset
- + CFV4E_FLAG (output_bfd) ? 8 : 2),
+ + (CFV4E_FLAG (output_bfd) ? 8 : 2)),
     splt->contents + h->plt.offset + plt_off1);

       bfd_put_32 (output_bfd, plt_index * sizeof (Elf32_External_Rela),
@@ -1884,7 +1884,7 @@ elf_m68k_finish_dynamic_symbol (output_b
     (splt->output_section->vma
      + splt->output_offset
      + h->plt.offset
- + CFV4E_FLAG (output_bfd) ? 12 : 8),
+ + (CFV4E_FLAG (output_bfd) ? 12 : 8)),
     sgot->contents + got_offset);

       /* Fill in the entry in the .rela.plt section. */

--
Alan Modra
IBM OzLabs - Linux Technology Centre

----- End forwarded message -----

--
.../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/
../ --/ ./ / .--/ ../ -/ ..../ / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/
-.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ /
../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ ..../ -./ ---/ .-../
---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/

Revision history for this message
In , James Troup (james-nocrew) wrote : Bug#327780: fixed in binutils 2.16.1cvs20051109-1
Download full text (4.9 KiB)

Source: binutils
Source-Version: 2.16.1cvs20051109-1

We believe that the bug you reported is fixed in the latest version of
binutils, which is due to be installed in the Debian FTP archive:

binutils-dev_2.16.1cvs20051109-1_i386.deb
  to pool/main/b/binutils/binutils-dev_2.16.1cvs20051109-1_i386.deb
binutils-doc_2.16.1cvs20051109-1_all.deb
  to pool/main/b/binutils/binutils-doc_2.16.1cvs20051109-1_all.deb
binutils-multiarch_2.16.1cvs20051109-1_i386.deb
  to pool/main/b/binutils/binutils-multiarch_2.16.1cvs20051109-1_i386.deb
binutils_2.16.1cvs20051109-1.diff.gz
  to pool/main/b/binutils/binutils_2.16.1cvs20051109-1.diff.gz
binutils_2.16.1cvs20051109-1.dsc
  to pool/main/b/binutils/binutils_2.16.1cvs20051109-1.dsc
binutils_2.16.1cvs20051109-1_i386.deb
  to pool/main/b/binutils/binutils_2.16.1cvs20051109-1_i386.deb
binutils_2.16.1cvs20051109.orig.tar.gz
  to pool/main/b/binutils/binutils_2.16.1cvs20051109.orig.tar.gz

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to <email address hidden>,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
James Troup <email address hidden> (supplier of updated binutils package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing <email address hidden>)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Fri, 11 Nov 2005 20:38:22 +0000
Source: binutils
Binary: binutils-dev binutils-hppa64 binutils-multiarch binutils binutils-doc
Architecture: source i386 all
Version: 2.16.1cvs20051109-1
Distribution: unstable
Urgency: low
Maintainer: James Troup <email address hidden>
Changed-By: James Troup <email address hidden>
Description:
 binutils - The GNU assembler, linker and binary utilities
 binutils-dev - The GNU binary utilities (BFD development files)
 binutils-doc - Documentation for the GNU assembler, linker and binary utilities
 binutils-multiarch - Binary utilities that support multi-arch targets
Closes: 326103 327780 333980 334626 334673 336175 336939
Changes:
 binutils (2.16.1cvs20051109-1) unstable; urgency=low
 .
   * New upstream CVS snapshot.
    * Fixes broken PLT handling on m68k. Closes: #327780
    * Don't compile flex files with -Werror, fixing mips builds.
      Closes: #333980
    * Don't check undefined symbols introduced by "ld -u" for TLS. Closes:
      #326103
 .
   * 117_mips_symbolic_link.dpatch: merged upstream - removed.
 .
   * debian/rules: pass --disable-werror on ia64 as current gcc generates
     too many false positives. Closes: #336939
 .
   * 125_fix_tc_arm_cast.dpatch: new patch from Lennert Buytenhek to fix
     cast warning and arm builds. Closes: #336175
 .
   * 121_i386_x86_64_biarch.dpatch: imported from Ubuntu at request of
     Daniel Jacobwitz to fix biarch linking on i386/amd64. Closes:
     #334626, #334673
 .
   * debian/rules: remove any reference to pkgstriptranslations - an
     Ubuntu-ism that shouldn't have been in the Debian package in the first
  ...

Read more...

Revision history for this message
Debian Bug Importer (debzilla) wrote :
Download full text (5.2 KiB)

Message-Id: <email address hidden>
Date: Sat, 12 Nov 2005 04:02:10 -0800
From: James Troup <email address hidden>
To: <email address hidden>
Subject: Bug#327780: fixed in binutils 2.16.1cvs20051109-1

Source: binutils
Source-Version: 2.16.1cvs20051109-1

We believe that the bug you reported is fixed in the latest version of
binutils, which is due to be installed in the Debian FTP archive:

binutils-dev_2.16.1cvs20051109-1_i386.deb
  to pool/main/b/binutils/binutils-dev_2.16.1cvs20051109-1_i386.deb
binutils-doc_2.16.1cvs20051109-1_all.deb
  to pool/main/b/binutils/binutils-doc_2.16.1cvs20051109-1_all.deb
binutils-multiarch_2.16.1cvs20051109-1_i386.deb
  to pool/main/b/binutils/binutils-multiarch_2.16.1cvs20051109-1_i386.deb
binutils_2.16.1cvs20051109-1.diff.gz
  to pool/main/b/binutils/binutils_2.16.1cvs20051109-1.diff.gz
binutils_2.16.1cvs20051109-1.dsc
  to pool/main/b/binutils/binutils_2.16.1cvs20051109-1.dsc
binutils_2.16.1cvs20051109-1_i386.deb
  to pool/main/b/binutils/binutils_2.16.1cvs20051109-1_i386.deb
binutils_2.16.1cvs20051109.orig.tar.gz
  to pool/main/b/binutils/binutils_2.16.1cvs20051109.orig.tar.gz

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to <email address hidden>,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
James Troup <email address hidden> (supplier of updated binutils package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing <email address hidden>)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Fri, 11 Nov 2005 20:38:22 +0000
Source: binutils
Binary: binutils-dev binutils-hppa64 binutils-multiarch binutils binutils-doc
Architecture: source i386 all
Version: 2.16.1cvs20051109-1
Distribution: unstable
Urgency: low
Maintainer: James Troup <email address hidden>
Changed-By: James Troup <email address hidden>
Description:
 binutils - The GNU assembler, linker and binary utilities
 binutils-dev - The GNU binary utilities (BFD development files)
 binutils-doc - Documentation for the GNU assembler, linker and binary utilities
 binutils-multiarch - Binary utilities that support multi-arch targets
Closes: 326103 327780 333980 334626 334673 336175 336939
Changes:
 binutils (2.16.1cvs20051109-1) unstable; urgency=low
 .
   * New upstream CVS snapshot.
    * Fixes broken PLT handling on m68k. Closes: #327780
    * Don't compile flex files with -Werror, fixing mips builds.
      Closes: #333980
    * Don't check undefined symbols introduced by "ld -u" for TLS. Closes:
      #326103
 .
   * 117_mips_symbolic_link.dpatch: merged upstream - removed.
 .
   * debian/rules: pass --disable-werror on ia64 as current gcc generates
     too many false positives. Closes: #336939
 .
   * 125_fix_tc_arm_cast.dpatch: new patch from Lennert Buytenhek to fix
     cast warning and arm builds. Closes: #336175
 .
   * 121_i386_x86_64_biarch.dpatch: imported from Ubuntu at request of
     Daniel Jacobwitz t...

Read more...

Revision history for this message
In , Bts-link-upstream (bts-link-upstream) wrote : [bts-link] source package binutils

#
# bts-link upstream status pull for source package binutils
# see http://lists.debian.org/debian-devel-announce/2006/05/msg00001.html
#

user <email address hidden>

# remote status report for #327780
# * http://sourceware.org/bugzilla/show_bug.cgi?id=1775
# * remote status changed: (?) -> RESOLVED
# * remote resolution changed: (?) -> FIXED
# * closed upstream
tags 327780 + fixed-upstream
usertags 327780 + status-RESOLVED resolution-FIXED

thanks

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.