current gcc-4.0 is utterly useless on m68k
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://
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#1 |
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#2 |
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://
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=
>
> 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>
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#3 |
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.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#4 |
# Automatically generated email from bts, devscripts version 2.9.5
reassign 327780 binutils 2.16.1cvs20050902-1
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#5 |
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://
> 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://
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #6 |
Automatically imported from Debian bug report #327780 http://
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Matthias Klose (doko) wrote : | #7 |
m68k only
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#8 |
# Automatically generated email from bts, devscripts version 2.9.7
retitle 327780 current binutils are utterly useless on m68k
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#9 |
# Automatically generated email from bts, devscripts version 2.8.14
submitter 327780 Wouter Verhelst <email address hidden>
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #10 |
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=
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
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #11 |
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
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #12 |
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://
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=
>
> 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>
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #13 |
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.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #14 |
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
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #15 |
Message-ID: <20050912075906
Date: Mon, 12 Sep 2005 09:59:06 +0200
From: Ingo Juergensmann <ij@2005.
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-
Content-
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://
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://
--4VrXvz3cwkc87Wze
Content-Type: application/
Content-
Content-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFDJTVKlCn
geJEg/uNgf1wkq+
=7nHw
-----END PGP SIGNATURE-----
--4VrXvz3cwkc87
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #16 |
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
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #17 |
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>
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#18 |
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-
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_
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
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #19 |
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-
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_
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
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#20 |
Has anyone considered, wild though this may sound, forwarding this to upstream
Bugzilla? http://
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]
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#21 |
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_
-
-#define CFV4E_FLAG(abfd) (elf_elfheader (abfd)->e_flags & EF_CFV4E)
-
-static const bfd_byte elf_cfv4e_
-{
- 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_
-{
- 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_
@@ -1013,8 +982,6 @@
{
if (CPU32_FLAG (dynobj))
s->size += PLT_CPU32_
- else if (CFV4E_FLAG (dynobj))
- s->size += CFV4E_PLT_
else
s->size += PLT_ENTRY_SIZE;
}
@@ -1036,8 +1003,6 @@
/* Make room for this entry. */
if (CPU32_FLAG (dynobj))
s->size += PLT_CPU32_
- else if (CFV4E_FLAG (dynobj))
- s->size += CFV4E_PLT_
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_
- else if (CFV4E_FLAG (output_bfd))
- plt_index = (h->plt.offset / CFV4E_PLT_
+ if ( CPU32_FLAG (output_bfd))
+ plt_index = h->plt.offset / PLT_CPU32_
...
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #22 |
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://
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]
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #23 |
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_
-
-#define CFV4E_FLAG(abfd) (elf_elfheader (abfd)->e_flags & EF_CFV4E)
-
-static const bfd_byte elf_cfv4e_
-{
- 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_
-{
- 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_
@@ -1013,8 +982,6 @@
{
if (CPU32_FLAG (dynobj))
s->size += PLT_CPU32_
- else if (CFV4E_FLAG (dynobj))
- s->size += CFV4E_PLT_
else
s->size += PLT_ENTRY_SIZE;
}
@@ -1036,8 +1003,6 @@
/* Make room for this entry. */
if (CPU32_FLAG (dynobj))
s->size += PLT_CPU32_
- else if (CFV4E_FLAG (dynobj))
- s->size += CFV4E_PLT_
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_
- ...
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#24 |
package binutils
forwarded 327780 http://
thanks
--
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #25 |
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://
thanks
--
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#26 |
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_
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://
> 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_
parentheses.
Index: bfd/elf32-m68k.c
=======
RCS file: /cvs/src/
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_
+ got_offset
- (splt->
+ 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_
@@ -1884,7 +1884,7 @@ elf_m68k_
(splt-
+ 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 -----
--
.../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/
./ --/ ./ / .--/ ../ -/ ..../ / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/
-.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ /
./ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ ..../ -./ ---/ .-../
---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #27 |
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_
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://
> 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_
parentheses.
Index: bfd/elf32-m68k.c
=======
RCS file: /cvs/src/
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_
+ got_offset
- (splt->
+ 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_
@@ -1884,7 +1884,7 @@ elf_m68k_
(splt-
+ 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 -----
--
.../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/
../ --/ ./ / .--/ ../ -/ ..../ / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/
-.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ /
../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ ..../ -./ ---/ .-../
---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#28 |
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-
to pool/main/
binutils-
to pool/main/
binutils-
to pool/main/
binutils_
to pool/main/
binutils_
to pool/main/
binutils_
to pool/main/
binutils_
to pool/main/
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.1cvs20051
.
* 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_
.
* debian/rules: pass --disable-werror on ia64 as current gcc generates
too many false positives. Closes: #336939
.
* 125_fix_
cast warning and arm builds. Closes: #336175
.
* 121_i386_
Daniel Jacobwitz to fix biarch linking on i386/amd64. Closes:
#334626, #334673
.
* debian/rules: remove any reference to pkgstriptransla
Ubuntu-ism that shouldn't have been in the Debian package in the first
...
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #29 |
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-
to pool/main/
binutils-
to pool/main/
binutils-
to pool/main/
binutils_
to pool/main/
binutils_
to pool/main/
binutils_
to pool/main/
binutils_
to pool/main/
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.1cvs20051
.
* 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_
.
* debian/rules: pass --disable-werror on ia64 as current gcc generates
too many false positives. Closes: #336939
.
* 125_fix_
cast warning and arm builds. Closes: #336175
.
* 121_i386_
Daniel Jacobwitz t...
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#30 |
#
# bts-link upstream status pull for source package binutils
# see http://
#
user <email address hidden>
# remote status report for #327780
# * http://
# * remote status changed: (?) -> RESOLVED
# * remote resolution changed: (?) -> FIXED
# * closed upstream
tags 327780 + fixed-upstream
usertags 327780 + status-RESOLVED resolution-FIXED
thanks
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