Bug #461303 “generates-bad-code regression” : Bugs : binutils package : Ubuntu

Colin Watson (cjwatson) on 2009-10-26

affects:	ubuntu → gcc-4.4 (Ubuntu)
tags:	added: regression-potential

Revision history for this message

Zooko Wilcox-O'Hearn (zooko) wrote on 2009-10-26:

#1

Hold on, the reason that I stated that g++ 4.4.1-3ubuntu3 built good code is as follows:

1. The resulting libcrypto++8 is in Karmic, so it must have passed its self-test which happens automatically when you build it, right?

2. If you link pycryptopp to the resulting libcrypto++8 which is in Karmic, the pycryptopp passes all of its self-tests including under valgrind: here is the builder which does this: http://allmydata.org/buildbot-pycryptopp/builders/linux-amd64-ubuntu-karmic-yukyuk-syslib (in contrast, here is the builder which attempts to build the same version of pycryptopp but compile Crypto++ itself from source instead of using the libcrypto++8 which is included in Karmic: http://allmydata.org/buildbot-pycryptopp/builders/linux-amd64-ubuntu-karmic-yukyuk . That one fails.)

However, I just now finished getting a pbuilder chroot configured with g++-4.4 4.4.1-3ubuntu3 and when I pbuild libcrypto++8 then it hangs in its SHA self-test!

So, how did libcrypto++8 as built by g++ 4.4.1-3ubuntu3 pass its self tests? Or *did* it pass its self-tests before it went into Karmic?

Revision history for this message

Zooko Wilcox-O'Hearn (zooko) wrote on 2009-10-26:

#2

Okay it looks like this is an issue in binutils, not in g++. As stated in the previous comment I installed the version of g++-4.4 and all of its many dependencies that had been used back in 2009-09-18 to build libcrypto++8, and the build still fails. Then I changed binutils from the current (2.20-0ubuntu1) to the 2009-09-18 vintage: 2.19.91.20090910-0ubuntu1 . Now the build passes!

So to reiterate the only change I made in my pbuilder root was to install binutils 2.19.91.20090910-0ubuntu1, replacing binutils 2.20-0ubuntu1, and this made the pbuild of libcrypto++8 go from hanging during the SHA validation to passing.

Revision history for this message

Zooko Wilcox-O'Hearn (zooko) wrote on 2009-10-26:

#3

Okay I just did this:

Preparing to replace binutils 2.19.91.20090910-0ubuntu1 (using binutils_2.19.91.20091014-0ubuntu1_amd64.deb) ...

And am now pbuilding again. Now we'll see if the regression happened between 2.19.91.20090910-0ubuntu1 and 2.19.91.20091014-0ubuntu1 or between 2.19.91.20091014-0ubuntu1 and 2.20-0ubuntu1.

Revision history for this message

Zooko Wilcox-O'Hearn (zooko) wrote on 2009-10-26:

#4

Okay, the result is that 2.19.91.20091014-0ubuntu1 also misbuilds libcrypto++8.

Next I will try the point halfway between the last known good version (2.19.91.20090910-0ubuntu1) and the earliest known bad version (2.19.91.20091014-0ubuntu1). That would be... 2.19.91.20091003-0ubuntu1 . And while it is building I am going to take a nap.

Revision history for this message

Zooko Wilcox-O'Hearn (zooko) wrote on 2009-10-26:

#5

Oh by the way this is all on amd64.

Revision history for this message

Zooko Wilcox-O'Hearn (zooko) wrote on 2009-10-26:

#6

Okay, 2.19.91.20091003-0ubuntu1 passed. So the regression must be between 2.19.91.20091003-0ubuntu1 and 2.19.91.20091014-0ubuntu1 . Next I will try 2.19.91.20091005-0ubuntu2 .

Revision history for this message

Zooko Wilcox-O'Hearn (zooko) wrote on 2009-10-26:

#7

okay 2.19.91.20091005-0ubuntu2 built it correctly. We must be getting close to the regressing version. Next I'll try 2.19.91.20091006-0ubuntu1 .

Revision history for this message

Zooko Wilcox-O'Hearn (zooko) wrote on 2009-10-26:

#8

Preparing to replace binutils 2.19.91.20091005-0ubuntu2 (using binutils_2.19.91.20091006-0ubuntu1_amd64.deb) ...

Okay it passed. This implies that the upgrade from 2.19.91.20091006-0ubuntu1 to 2.19.91.20091014-0ubuntu1 introduced this regression. I'll just double-check that 2.19.91.20091014-0ubuntu1 still builds libcrypto++8 wrong...

Revision history for this message

Zooko Wilcox-O'Hearn (zooko) wrote on 2009-10-26:

#9

Preparing to replace binutils 2.19.91.20091006-0ubuntu1 (using binutils_2.19.91.20091014-0ubuntu1_amd64.deb) ...

Yep. 2.19.91.20091014-0ubuntu1 builds a libcrypto++8 that hangs during the SHA validation in its self-tests. What's the next step? How can we get a diff from 2.19.91.20091006-0ubuntu1 to 2.19.91.20091014-0ubuntu1?

Kees Cook (kees) on 2009-10-26

affects:

gcc-4.4 (Ubuntu) → binutils (Ubuntu)

Revision history for this message

Colin Watson (cjwatson) wrote on 2009-10-26:

#10

http://launchpadlibrarian.net/33666914/binutils_2.19.91.20091006-0ubuntu1_2.19.91.20091014-0ubuntu1.diff.gz

(linked from https://launchpad.net/ubuntu/+source/binutils/2.19.91.20091014-0ubuntu1)

Revision history for this message

Zooko Wilcox-O'Hearn (zooko) wrote on 2009-10-26:

#11

note that libcrypto++ does include a fair bit of asm code for amd64.

Revision history for this message

Zooko Wilcox-O'Hearn (zooko) wrote on 2009-10-26:

#12

Download full text (18.9 KiB)

okay, i'm not at all familiar with binutils, but just studying which files were changed by this patch and excluding build, packaging, translation, and non-amd64 arches, i am left with these three patches:

--- binutils-2.19.91.20091006/gas/read.c 2009-09-15 13:27:21.000000000 +0100
+++ binutils-2.19.91.20091014/gas/read.c 2009-10-07 09:35:59.000000000 +0100
@@ -3911,7 +3911,7 @@
   if (*input_line_pointer == ',')
     {
       ++input_line_pointer;
- expression_and_evaluate (&exp);
+ expression (&exp);
     }
   switch (exp.X_op)
     {
--- binutils-2.19.91.20091006/gas/symbols.c 2009-09-27 10:57:37.000000000 +0100
+++ binutils-2.19.91.20091014/gas/symbols.c 2009-10-07 09:36:44.000000000 +0100
@@ -1514,10 +1514,7 @@
      }
  }

- /* Never change a defined symbol. */
- if (symbolP->bsym->section == undefined_section
- || symbolP->bsym->section == expr_section)
- *symbolPP = symbolP;
+ *symbolPP = symbolP;
       *valueP = expr.X_add_number;
       *segP = symbolP->bsym->section;
       *fragPP = symbolP->sy_frag;
--- binutils-2.19.91.20091006/ld/scripttempl/elf.sc 2009-09-29 10:51:03.000000000 +0100
+++ binutils-2.19.91.20091014/ld/scripttempl/elf.sc 2009-10-09 06:43:07.000000000 +0100
@@ -110,42 +110,42 @@
   DATA_SEGMENT_RELRO_END=". = DATA_SEGMENT_RELRO_END (${SEPARATE_GOTPLT-0}, .);"
fi
if test -z "${INITIAL_READONLY_SECTIONS}${CREATE_SHLIB}"; then
- INITIAL_READONLY_SECTIONS=".interp : { *(.interp) }"
+ INITIAL_READONLY_SECTIONS=".interp ${RELOCATING-0} : { *(.interp) }"
fi
if test -z "$PLT"; then
- IPLT=".iplt : { *(.iplt) }"
- PLT=".plt : { *(.plt)${IREL_IN_PLT+ *(.iplt)} }
+ IPLT=".iplt ${RELOCATING-0} : { *(.iplt) }"
+ PLT=".plt ${RELOCATING-0} : { *(.plt)${IREL_IN_PLT+ *(.iplt)} }
   ${IREL_IN_PLT-$IPLT}"
fi
test -n "${DATA_PLT-${BSS_PLT-text}}" && TEXT_PLT=yes
if test -z "$GOT"; then
   if test -z "$SEPARATE_GOTPLT"; then
- GOT=".got : { *(.got.plt) *(.igot.plt) *(.got) *(.igot) }"
+ GOT=".got ${RELOCATING-0} : { *(.got.plt) *(.igot.plt) *(.got) *(.igot) }"
   else
- GOT=".got : { *(.got) *(.igot) }"
- GOTPLT=".got.plt : { *(.got.plt) *(.igot.plt) }"
+ GOT=".got ${RELOCATING-0} : { *(.got) *(.igot) }"
+ GOTPLT=".got.plt ${RELOCATING-0} : { *(.got.plt) *(.igot.plt) }"
   fi
fi
-REL_IFUNC=".rel.ifunc : { *(.rel.ifunc) }"
-RELA_IFUNC=".rela.ifunc : { *(.rela.ifunc) }"
-REL_IPLT=".rel.iplt :
+REL_IFUNC=".rel.ifunc ${RELOCATING-0} : { *(.rel.ifunc) }"
+RELA_IFUNC=".rela.ifunc ${RELOCATING-0} : { *(.rela.ifunc) }"
+REL_IPLT=".rel.iplt ${RELOCATING-0} :
     {
       ${RELOCATING+${CREATE_SHLIB-PROVIDE_HIDDEN (${USER_LABEL_PREFIX}__rel_iplt_start = .);}}
       *(.rel.iplt)
       ${RELOCATING+${CREATE_SHLIB-PROVIDE_HIDDEN (${USER_LABEL_PREFIX}__rel_iplt_end = .);}}
     }"
-RELA_IPLT=".rela.iplt :
+RELA_IPLT=".rela.iplt ${RELOCATING-0} :
     {
       ${RELOCATING+${CREATE_SHLIB-PROVIDE_HIDDEN (${USER_LABEL_PREFIX}__rela_iplt_start = .);}}
       *(.rela.iplt)
       ${RELOCATING+${CREATE_SHLIB-PROVIDE_HIDDEN (${USER_LABEL_PREFIX}__rela_iplt_end = .);}...

okay, i'm not at all familiar with binutils, but just studying which files were changed by this patch and excluding build, packaging, translation, and non-amd64 arches, i am left with these three patches:

--- binutils-2.19.91.20091006/gas/read.c	2009-09-15 13:27:21.000000000 +0100
+++ binutils-2.19.91.20091014/gas/read.c	2009-10-07 09:35:59.000000000 +0100
@@ -3911,7 +3911,7 @@
   if (*input_line_pointer == ',')
     {
       ++input_line_pointer;
-      expression_and_evaluate (&exp);
+      expression (&exp);
     }
   switch (exp.X_op)
     {
--- binutils-2.19.91.20091006/gas/symbols.c	2009-09-27 10:57:37.000000000 +0100
+++ binutils-2.19.91.20091014/gas/symbols.c	2009-10-07 09:36:44.000000000 +0100
@@ -1514,10 +1514,7 @@
 	    }
 	}
 
-      /* Never change a defined symbol.  */
-      if (symbolP->bsym->section == undefined_section
-	  || symbolP->bsym->section == expr_section)
-	*symbolPP = symbolP;
+      *symbolPP = symbolP;
       *valueP = expr.X_add_number;
       *segP = symbolP->bsym->section;
       *fragPP = symbolP->sy_frag;
--- binutils-2.19.91.20091006/ld/scripttempl/elf.sc	2009-09-29 10:51:03.000000000 +0100
+++ binutils-2.19.91.20091014/ld/scripttempl/elf.sc	2009-10-09 06:43:07.000000000 +0100
@@ -110,42 +110,42 @@
   DATA_SEGMENT_RELRO_END=". = DATA_SEGMENT_RELRO_END (${SEPARATE_GOTPLT-0}, .);"
 fi
 if test -z "${INITIAL_READONLY_SECTIONS}${CREATE_SHLIB}"; then
-  INITIAL_READONLY_SECTIONS=".interp        : { *(.interp) }"
+  INITIAL_READONLY_SECTIONS=".interp       ${RELOCATING-0} : { *(.interp) }"
 fi
 if test -z "$PLT"; then
-  IPLT=".iplt          : { *(.iplt) }"
-  PLT=".plt           : { *(.plt)${IREL_IN_PLT+ *(.iplt)} }
+  IPLT=".iplt         ${RELOCATING-0} : { *(.iplt) }"
+  PLT=".plt          ${RELOCATING-0} : { *(.plt)${IREL_IN_PLT+ *(.iplt)} }
   ${IREL_IN_PLT-$IPLT}"
 fi
 test -n "${DATA_PLT-${BSS_PLT-text}}" && TEXT_PLT=yes
 if test -z "$GOT"; then
   if test -z "$SEPARATE_GOTPLT"; then
-    GOT=".got           : { *(.got.plt) *(.igot.plt) *(.got) *(.igot) }"
+    GOT=".got          ${RELOCATING-0} : { *(.got.plt) *(.igot.plt) *(.got) *(.igot) }"
   else
-    GOT=".got           : { *(.got) *(.igot) }"
-    GOTPLT=".got.plt       : { *(.got.plt)  *(.igot.plt) }"
+    GOT=".got          ${RELOCATING-0} : { *(.got) *(.igot) }"
+    GOTPLT=".got.plt      ${RELOCATING-0} : { *(.got.plt)  *(.igot.plt) }"
   fi
 fi
-REL_IFUNC=".rel.ifunc     : { *(.rel.ifunc) }"
-RELA_IFUNC=".rela.ifunc    : { *(.rela.ifunc) }"
-REL_IPLT=".rel.iplt      :
+REL_IFUNC=".rel.ifunc    ${RELOCATING-0} : { *(.rel.ifunc) }"
+RELA_IFUNC=".rela.ifunc   ${RELOCATING-0} : { *(.rela.ifunc) }"
+REL_IPLT=".rel.iplt     ${RELOCATING-0} :
     {
       ${RELOCATING+${CREATE_SHLIB-PROVIDE_HIDDEN (${USER_LABEL_PREFIX}__rel_iplt_start = .);}}
       *(.rel.iplt)
       ${RELOCATING+${CREATE_SHLIB-PROVIDE_HIDDEN (${USER_LABEL_PREFIX}__rel_iplt_end = .);}}
     }"
-RELA_IPLT=".rela.iplt     :
+RELA_IPLT=".rela.iplt    ${RELOCATING-0} :
     {
       ${RELOCATING+${CREATE_SHLIB-PROVIDE_HIDDEN (${USER_LABEL_PREFIX}__rela_iplt_start = .);}}
       *(.rela.iplt)
       ${RELOCATING+${CREATE_SHLIB-PROVIDE_HIDDEN (${USER_LABEL_PREFIX}__rela_iplt_end = .);}}
     }"
-DYNAMIC=".dynamic       : { *(.dynamic) }"
-RODATA=".rodata        : { *(.rodata${RELOCATING+ .rodata.* .gnu.linkonce.r.*}) }"
+DYNAMIC=".dynamic      ${RELOCATING-0} : { *(.dynamic) }"
+RODATA=".rodata       ${RELOCATING-0} : { *(.rodata${RELOCATING+ .rodata.* .gnu.linkonce.r.*}) }"
 DATARELRO=".data.rel.ro : { *(.data.rel.ro.local* .gnu.linkonce.d.rel.ro.local.*) *(.data.rel.ro* .gnu.linkonce.d.rel.ro.*) }"
 DISCARDED="/DISCARD/ : { *(.note.GNU-stack) *(.gnu_debuglink) *(.gnu.lto_*) }"
 if test -z "${NO_SMALL_DATA}"; then
-  SBSS=".sbss          :
+  SBSS=".sbss         ${RELOCATING-0} :
   {
     ${RELOCATING+${SBSS_START_SYMBOLS}}
     ${CREATE_SHLIB+*(.sbss2 .sbss2.* .gnu.linkonce.sb2.*)}
@@ -154,29 +154,29 @@
     *(.scommon)
     ${RELOCATING+${SBSS_END_SYMBOLS}}
   }"
-  SBSS2=".sbss2         : { *(.sbss2${RELOCATING+ .sbss2.* .gnu.linkonce.sb2.*}) }"
+  SBSS2=".sbss2        ${RELOCATING-0} : { *(.sbss2${RELOCATING+ .sbss2.* .gnu.linkonce.sb2.*}) }"
   SDATA="/* We want the small data sections together, so single-instruction offsets
      can access them all, and initialized data all before uninitialized, so
      we can shorten the on-disk segment size.  */
-  .sdata         : 
+  .sdata        ${RELOCATING-0} : 
   {
     ${RELOCATING+${SDATA_START_SYMBOLS}}
     ${CREATE_SHLIB+*(.sdata2 .sdata2.* .gnu.linkonce.s2.*)}
     *(.sdata${RELOCATING+ .sdata.* .gnu.linkonce.s.*})
   }"
-  SDATA2=".sdata2        :
+  SDATA2=".sdata2       ${RELOCATING-0} :
   {
     ${RELOCATING+${SDATA2_START_SYMBOLS}}
     *(.sdata2${RELOCATING+ .sdata2.* .gnu.linkonce.s2.*})
   }"
-  REL_SDATA=".rel.sdata     : { *(.rel.sdata${RELOCATING+ .rel.sdata.* .rel.gnu.linkonce.s.*}) }
-  .rela.sdata    : { *(.rela.sdata${RELOCATING+ .rela.sdata.* .rela.gnu.linkonce.s.*}) }"
-  REL_SBSS=".rel.sbss      : { *(.rel.sbss${RELOCATING+ .rel.sbss.* .rel.gnu.linkonce.sb.*}) }
-  .rela.sbss     : { *(.rela.sbss${RELOCATING+ .rela.sbss.* .rela.gnu.linkonce.sb.*}) }"
-  REL_SDATA2=".rel.sdata2    : { *(.rel.sdata2${RELOCATING+ .rel.sdata2.* .rel.gnu.linkonce.s2.*}) }
-  .rela.sdata2   : { *(.rela.sdata2${RELOCATING+ .rela.sdata2.* .rela.gnu.linkonce.s2.*}) }"
-  REL_SBSS2=".rel.sbss2     : { *(.rel.sbss2${RELOCATING+ .rel.sbss2.* .rel.gnu.linkonce.sb2.*}) }
-  .rela.sbss2    : { *(.rela.sbss2${RELOCATING+ .rela.sbss2.* .rela.gnu.linkonce.sb2.*}) }"
+  REL_SDATA=".rel.sdata    ${RELOCATING-0} : { *(.rel.sdata${RELOCATING+ .rel.sdata.* .rel.gnu.linkonce.s.*}) }
+  .rela.sdata   ${RELOCATING-0} : { *(.rela.sdata${RELOCATING+ .rela.sdata.* .rela.gnu.linkonce.s.*}) }"
+  REL_SBSS=".rel.sbss     ${RELOCATING-0} : { *(.rel.sbss${RELOCATING+ .rel.sbss.* .rel.gnu.linkonce.sb.*}) }
+  .rela.sbss    ${RELOCATING-0} : { *(.rela.sbss${RELOCATING+ .rela.sbss.* .rela.gnu.linkonce.sb.*}) }"
+  REL_SDATA2=".rel.sdata2   ${RELOCATING-0} : { *(.rel.sdata2${RELOCATING+ .rel.sdata2.* .rel.gnu.linkonce.s2.*}) }
+  .rela.sdata2  ${RELOCATING-0} : { *(.rela.sdata2${RELOCATING+ .rela.sdata2.* .rela.gnu.linkonce.s2.*}) }"
+  REL_SBSS2=".rel.sbss2    ${RELOCATING-0} : { *(.rel.sbss2${RELOCATING+ .rel.sbss2.* .rel.gnu.linkonce.sb2.*}) }
+  .rela.sbss2   ${RELOCATING-0} : { *(.rela.sbss2${RELOCATING+ .rela.sbss2.* .rela.gnu.linkonce.sb2.*}) }"
 else
   NO_SMALL_DATA=" "
 fi
@@ -192,31 +192,31 @@
 fi
 test -n "$SEPARATE_GOTPLT" && SEPARATE_GOTPLT=" "
 test "${LARGE_SECTIONS}" = "yes" && REL_LARGE="
-  .rel.ldata     : { *(.rel.ldata${RELOCATING+ .rel.ldata.* .rel.gnu.linkonce.l.*}) }
-  .rela.ldata    : { *(.rela.ldata${RELOCATING+ .rela.ldata.* .rela.gnu.linkonce.l.*}) }
-  .rel.lbss      : { *(.rel.lbss${RELOCATING+ .rel.lbss.* .rel.gnu.linkonce.lb.*}) }
-  .rela.lbss     : { *(.rela.lbss${RELOCATING+ .rela.lbss.* .rela.gnu.linkonce.lb.*}) }
-  .rel.lrodata   : { *(.rel.lrodata${RELOCATING+ .rel.lrodata.* .rel.gnu.linkonce.lr.*}) }
-  .rela.lrodata  : { *(.rela.lrodata${RELOCATING+ .rela.lrodata.* .rela.gnu.linkonce.lr.*}) }"
+  .rel.ldata    ${RELOCATING-0} : { *(.rel.ldata${RELOCATING+ .rel.ldata.* .rel.gnu.linkonce.l.*}) }
+  .rela.ldata   ${RELOCATING-0} : { *(.rela.ldata${RELOCATING+ .rela.ldata.* .rela.gnu.linkonce.l.*}) }
+  .rel.lbss     ${RELOCATING-0} : { *(.rel.lbss${RELOCATING+ .rel.lbss.* .rel.gnu.linkonce.lb.*}) }
+  .rela.lbss    ${RELOCATING-0} : { *(.rela.lbss${RELOCATING+ .rela.lbss.* .rela.gnu.linkonce.lb.*}) }
+  .rel.lrodata  ${RELOCATING-0} : { *(.rel.lrodata${RELOCATING+ .rel.lrodata.* .rel.gnu.linkonce.lr.*}) }
+  .rela.lrodata ${RELOCATING-0} : { *(.rela.lrodata${RELOCATING+ .rela.lrodata.* .rela.gnu.linkonce.lr.*}) }"
 test "${LARGE_SECTIONS}" = "yes" && OTHER_BSS_SECTIONS="
   ${OTHER_BSS_SECTIONS}
-  .lbss  :
+  .lbss ${RELOCATING-0} :
   {
     *(.dynlbss)
     *(.lbss${RELOCATING+ .lbss.* .gnu.linkonce.lb.*})
     *(LARGE_COMMON)
   }"
 test "${LARGE_SECTIONS}" = "yes" && LARGE_SECTIONS="
-  .lrodata  ${RELOCATING+ALIGN(${MAXPAGESIZE}) + (. & (${MAXPAGESIZE} - 1))} :
+  .lrodata ${RELOCATING-0} ${RELOCATING+ALIGN(${MAXPAGESIZE}) + (. & (${MAXPAGESIZE} - 1))} :
   {
     *(.lrodata${RELOCATING+ .lrodata.* .gnu.linkonce.lr.*})
   }
-  .ldata  ${RELOCATING+ALIGN(${MAXPAGESIZE}) + (. & (${MAXPAGESIZE} - 1))} :
+  .ldata ${RELOCATING-0} ${RELOCATING+ALIGN(${MAXPAGESIZE}) + (. & (${MAXPAGESIZE} - 1))} :
   {
     *(.ldata${RELOCATING+ .ldata.* .gnu.linkonce.l.*})
     ${RELOCATING+. = ALIGN(. != 0 ? ${ALIGNMENT} : 1);}
   }"
-CTOR=".ctors         : 
+CTOR=".ctors        ${CONSTRUCTING-0} : 
   {
     ${CONSTRUCTING+${CTOR_START}}
     /* gcc uses crtbegin.o to find the start of
@@ -242,7 +242,7 @@
     KEEP (*(.ctors))
     ${CONSTRUCTING+${CTOR_END}}
   }"
-DTOR=".dtors         :
+DTOR=".dtors        ${CONSTRUCTING-0} :
   {
     ${CONSTRUCTING+${DTOR_START}}
     KEEP (*crtbegin.o(.dtors))
@@ -252,7 +252,7 @@
     KEEP (*(.dtors))
     ${CONSTRUCTING+${DTOR_END}}
   }"
-STACK="  .stack        ${RELOCATING+${STACK_ADDR}} :
+STACK="  .stack        ${RELOCATING-0}${RELOCATING+${STACK_ADDR}} :
   {
     ${RELOCATING+${USER_LABEL_PREFIX}_stack = .;}
     *(.stack)
@@ -277,6 +277,10 @@
 ${RELOCATING+${LIB_SEARCH_DIRS}}
 ${RELOCATING+${EXECUTABLE_SYMBOLS}}
 ${RELOCATING+${INPUT_FILES}}
+${RELOCATING- /* For some reason, the Solaris linker makes bad executables
+  if gld -r is used and the intermediate file has sections starting
+  at non-zero addresses.  Could be a Solaris ld bug, could be a GNU ld
+  bug.  But for now assigning the zero vmas works.  */}
 
 SECTIONS
 {
@@ -292,13 +296,13 @@
 test -z "${NON_ALLOC_DYN}" || TEXT_DYNAMIC=
 cat > ldscripts/dyntmp.$$ <<EOF
   ${TEXT_DYNAMIC+${DYNAMIC}}
-  .hash          : { *(.hash) }
-  .gnu.hash      : { *(.gnu.hash) }
-  .dynsym        : { *(.dynsym) }
-  .dynstr        : { *(.dynstr) }
-  .gnu.version   : { *(.gnu.version) }
-  .gnu.version_d : { *(.gnu.version_d) }
-  .gnu.version_r : { *(.gnu.version_r) }
+  .hash         ${RELOCATING-0} : { *(.hash) }
+  .gnu.hash     ${RELOCATING-0} : { *(.gnu.hash) }
+  .dynsym       ${RELOCATING-0} : { *(.dynsym) }
+  .dynstr       ${RELOCATING-0} : { *(.dynstr) }
+  .gnu.version  ${RELOCATING-0} : { *(.gnu.version) }
+  .gnu.version_d ${RELOCATING-0}: { *(.gnu.version_d) }
+  .gnu.version_r ${RELOCATING-0}: { *(.gnu.version_r) }
 EOF
 
 if [ "x$COMBRELOC" = x ]; then
@@ -307,36 +311,36 @@
   COMBRELOCCAT="cat > $COMBRELOC"
 fi
 eval $COMBRELOCCAT <<EOF
-  .rel.init      : { *(.rel.init) }
-  .rela.init     : { *(.rela.init) }
-  .rel.text      : { *(.rel.text${RELOCATING+ .rel.text.* .rel.gnu.linkonce.t.*}) }
-  .rela.text     : { *(.rela.text${RELOCATING+ .rela.text.* .rela.gnu.linkonce.t.*}) }
-  .rel.fini      : { *(.rel.fini) }
-  .rela.fini     : { *(.rela.fini) }
-  .rel.rodata    : { *(.rel.rodata${RELOCATING+ .rel.rodata.* .rel.gnu.linkonce.r.*}) }
-  .rela.rodata   : { *(.rela.rodata${RELOCATING+ .rela.rodata.* .rela.gnu.linkonce.r.*}) }
+  .rel.init     ${RELOCATING-0} : { *(.rel.init) }
+  .rela.init    ${RELOCATING-0} : { *(.rela.init) }
+  .rel.text     ${RELOCATING-0} : { *(.rel.text${RELOCATING+ .rel.text.* .rel.gnu.linkonce.t.*}) }
+  .rela.text    ${RELOCATING-0} : { *(.rela.text${RELOCATING+ .rela.text.* .rela.gnu.linkonce.t.*}) }
+  .rel.fini     ${RELOCATING-0} : { *(.rel.fini) }
+  .rela.fini    ${RELOCATING-0} : { *(.rela.fini) }
+  .rel.rodata   ${RELOCATING-0} : { *(.rel.rodata${RELOCATING+ .rel.rodata.* .rel.gnu.linkonce.r.*}) }
+  .rela.rodata  ${RELOCATING-0} : { *(.rela.rodata${RELOCATING+ .rela.rodata.* .rela.gnu.linkonce.r.*}) }
   ${OTHER_READONLY_RELOC_SECTIONS}
-  .rel.data.rel.ro  : { *(.rel.data.rel.ro${RELOCATING+* .rel.gnu.linkonce.d.rel.ro.*}) }
-  .rela.data.rel.ro  : { *(.rela.data.rel.ro${RELOCATING+* .rela.gnu.linkonce.d.rel.ro.*}) }
-  .rel.data      : { *(.rel.data${RELOCATING+ .rel.data.* .rel.gnu.linkonce.d.*}) }
-  .rela.data     : { *(.rela.data${RELOCATING+ .rela.data.* .rela.gnu.linkonce.d.*}) }
-  .rel.tdata	 : { *(.rel.tdata${RELOCATING+ .rel.tdata.* .rel.gnu.linkonce.td.*}) }
-  .rela.tdata	 : { *(.rela.tdata${RELOCATING+ .rela.tdata.* .rela.gnu.linkonce.td.*}) }
-  .rel.tbss	 : { *(.rel.tbss${RELOCATING+ .rel.tbss.* .rel.gnu.linkonce.tb.*}) }
-  .rela.tbss	 : { *(.rela.tbss${RELOCATING+ .rela.tbss.* .rela.gnu.linkonce.tb.*}) }
-  .rel.ctors     : { *(.rel.ctors) }
-  .rela.ctors    : { *(.rela.ctors) }
-  .rel.dtors     : { *(.rel.dtors) }
-  .rela.dtors    : { *(.rela.dtors) }
-  .rel.got       : { *(.rel.got) }
-  .rela.got      : { *(.rela.got) }
+  .rel.data.rel.ro ${RELOCATING-0} : { *(.rel.data.rel.ro${RELOCATING+* .rel.gnu.linkonce.d.rel.ro.*}) }
+  .rela.data.rel.ro ${RELOCATING-0} : { *(.rela.data.rel.ro${RELOCATING+* .rela.gnu.linkonce.d.rel.ro.*}) }
+  .rel.data     ${RELOCATING-0} : { *(.rel.data${RELOCATING+ .rel.data.* .rel.gnu.linkonce.d.*}) }
+  .rela.data    ${RELOCATING-0} : { *(.rela.data${RELOCATING+ .rela.data.* .rela.gnu.linkonce.d.*}) }
+  .rel.tdata	${RELOCATING-0} : { *(.rel.tdata${RELOCATING+ .rel.tdata.* .rel.gnu.linkonce.td.*}) }
+  .rela.tdata	${RELOCATING-0} : { *(.rela.tdata${RELOCATING+ .rela.tdata.* .rela.gnu.linkonce.td.*}) }
+  .rel.tbss	${RELOCATING-0} : { *(.rel.tbss${RELOCATING+ .rel.tbss.* .rel.gnu.linkonce.tb.*}) }
+  .rela.tbss	${RELOCATING-0} : { *(.rela.tbss${RELOCATING+ .rela.tbss.* .rela.gnu.linkonce.tb.*}) }
+  .rel.ctors    ${RELOCATING-0} : { *(.rel.ctors) }
+  .rela.ctors   ${RELOCATING-0} : { *(.rela.ctors) }
+  .rel.dtors    ${RELOCATING-0} : { *(.rel.dtors) }
+  .rela.dtors   ${RELOCATING-0} : { *(.rela.dtors) }
+  .rel.got      ${RELOCATING-0} : { *(.rel.got) }
+  .rela.got     ${RELOCATING-0} : { *(.rela.got) }
   ${OTHER_GOT_RELOC_SECTIONS}
   ${REL_SDATA}
   ${REL_SBSS}
   ${REL_SDATA2}
   ${REL_SBSS2}
-  .rel.bss       : { *(.rel.bss${RELOCATING+ .rel.bss.* .rel.gnu.linkonce.b.*}) }
-  .rela.bss      : { *(.rela.bss${RELOCATING+ .rela.bss.* .rela.gnu.linkonce.b.*}) }
+  .rel.bss      ${RELOCATING-0} : { *(.rel.bss${RELOCATING+ .rel.bss.* .rel.gnu.linkonce.b.*}) }
+  .rela.bss     ${RELOCATING-0} : { *(.rela.bss${RELOCATING+ .rela.bss.* .rela.gnu.linkonce.b.*}) }
   ${REL_LARGE}
   ${IREL_IN_PLT+$REL_IFUNC}
   ${IREL_IN_PLT+$RELA_IFUNC}
@@ -346,13 +350,13 @@
 
 if [ -n "$COMBRELOC" ]; then
 cat >> ldscripts/dyntmp.$$ <<EOF
-  .rel.dyn       :
+  .rel.dyn      ${RELOCATING-0} :
     {
 EOF
 sed -e '/^[ 	]*[{}][ 	]*$/d;/:[ 	]*$/d;/\.rela\./d;s/^.*: { *$.*$}$/      \1/' $COMBRELOC >> ldscripts/dyntmp.$$
 cat >> ldscripts/dyntmp.$$ <<EOF
     }
-  .rela.dyn      :
+  .rela.dyn     ${RELOCATING-0} :
     {
 EOF
 sed -e '/^[ 	]*[{}][ 	]*$/d;/:[ 	]*$/d;/\.rel\./d;s/^.*: { *$.*$}/      \1/' $COMBRELOC >> ldscripts/dyntmp.$$
@@ -362,14 +366,14 @@
 fi
 
 cat >> ldscripts/dyntmp.$$ <<EOF
-  .rel.plt       :
+  .rel.plt      ${RELOCATING-0} :
     {
       *(.rel.plt)
       ${IREL_IN_PLT+${RELOCATING+${CREATE_SHLIB-PROVIDE_HIDDEN (${USER_LABEL_PREFIX}__rel_iplt_start = .);}}}
       ${IREL_IN_PLT+${RELOCATING+*(.rel.iplt)}}
       ${IREL_IN_PLT+${RELOCATING+${CREATE_SHLIB-PROVIDE_HIDDEN (${USER_LABEL_PREFIX}__rel_iplt_end = .);}}}
     }
-  .rela.plt      :
+  .rela.plt     ${RELOCATING-0} :
     {
       *(.rela.plt)
       ${IREL_IN_PLT+${RELOCATING+${CREATE_SHLIB-PROVIDE_HIDDEN (${USER_LABEL_PREFIX}__rela_iplt_start = .);}}}
@@ -394,7 +398,7 @@
 fi
 
 cat <<EOF
-  .init          : 
+  .init         ${RELOCATING-0} : 
   { 
     ${RELOCATING+${INIT_START}}
     KEEP (*(.init))
@@ -403,7 +407,7 @@
 
   ${TEXT_PLT+${PLT}}
   ${TINY_READONLY_SECTION}
-  .text          :
+  .text         ${RELOCATING-0} :
   {
     ${RELOCATING+${TEXT_START_SYMBOLS}}
     ${RELOCATING+*(.text.unlikely .text.*_unlikely)}
@@ -412,7 +416,7 @@
     *(.gnu.warning)
     ${RELOCATING+${OTHER_TEXT_SECTIONS}}
   } =${NOP-0}
-  .fini          :
+  .fini         ${RELOCATING-0} :
   {
     ${RELOCATING+${FINI_START}}
     KEEP (*(.fini))
@@ -422,13 +426,13 @@
   ${RELOCATING+PROVIDE (_${ETEXT_NAME} = .);}
   ${RELOCATING+PROVIDE (${ETEXT_NAME} = .);}
   ${WRITABLE_RODATA-${RODATA}}
-  .rodata1       : { *(.rodata1) }
+  .rodata1      ${RELOCATING-0} : { *(.rodata1) }
   ${CREATE_SHLIB-${SDATA2}}
   ${CREATE_SHLIB-${SBSS2}}
   ${OTHER_READONLY_SECTIONS}
   .eh_frame_hdr : { *(.eh_frame_hdr) }
-  .eh_frame      : ONLY_IF_RO { KEEP (*(.eh_frame)) }
-  .gcc_except_table  : ONLY_IF_RO { *(.gcc_except_table .gcc_except_table.*) }
+  .eh_frame     ${RELOCATING-0} : ONLY_IF_RO { KEEP (*(.eh_frame)) }
+  .gcc_except_table ${RELOCATING-0} : ONLY_IF_RO { *(.gcc_except_table .gcc_except_table.*) }
 
   /* Adjust the address for the data segment.  We want to adjust up to
      the same address within the page on the next page up.  */
@@ -437,27 +441,27 @@
   ${CREATE_PIE+${RELOCATING+. = ${SHLIB_DATA_ADDR-${DATA_SEGMENT_ALIGN}};}}
 
   /* Exception handling  */
-  .eh_frame      : ONLY_IF_RW { KEEP (*(.eh_frame)) }
-  .gcc_except_table  : ONLY_IF_RW { *(.gcc_except_table .gcc_except_table.*) }
+  .eh_frame     ${RELOCATING-0} : ONLY_IF_RW { KEEP (*(.eh_frame)) }
+  .gcc_except_table ${RELOCATING-0} : ONLY_IF_RW { *(.gcc_except_table .gcc_except_table.*) }
 
   /* Thread Local Storage sections  */
-  .tdata	 : { *(.tdata${RELOCATING+ .tdata.* .gnu.linkonce.td.*}) }
-  .tbss		 : { *(.tbss${RELOCATING+ .tbss.* .gnu.linkonce.tb.*})${RELOCATING+ *(.tcommon)} }
+  .tdata	${RELOCATING-0} : { *(.tdata${RELOCATING+ .tdata.* .gnu.linkonce.td.*}) }
+  .tbss		${RELOCATING-0} : { *(.tbss${RELOCATING+ .tbss.* .gnu.linkonce.tb.*})${RELOCATING+ *(.tcommon)} }
 
-  .preinit_array    :
+  .preinit_array   ${RELOCATING-0} :
   {
     ${RELOCATING+${CREATE_SHLIB-PROVIDE_HIDDEN (${USER_LABEL_PREFIX}__preinit_array_start = .);}}
     KEEP (*(.preinit_array))
     ${RELOCATING+${CREATE_SHLIB-PROVIDE_HIDDEN (${USER_LABEL_PREFIX}__preinit_array_end = .);}}
   }
-  .init_array    :
+  .init_array   ${RELOCATING-0} :
   {
      ${RELOCATING+${CREATE_SHLIB-PROVIDE_HIDDEN (${USER_LABEL_PREFIX}__init_array_start = .);}}
      KEEP (*(SORT(.init_array.*)))
      KEEP (*(.init_array))
      ${RELOCATING+${CREATE_SHLIB-PROVIDE_HIDDEN (${USER_LABEL_PREFIX}__init_array_end = .);}}
   }
-  .fini_array    :
+  .fini_array   ${RELOCATING-0} :
   {
     ${RELOCATING+${CREATE_SHLIB-PROVIDE_HIDDEN (${USER_LABEL_PREFIX}__fini_array_start = .);}}
     KEEP (*(.fini_array))
@@ -466,7 +470,7 @@
   }
   ${SMALL_DATA_CTOR-${RELOCATING+${CTOR}}}
   ${SMALL_DATA_DTOR-${RELOCATING+${DTOR}}}
-  .jcr           : { KEEP (*(.jcr)) }
+  .jcr          ${RELOCATING-0} : { KEEP (*(.jcr)) }
 
   ${RELOCATING+${DATARELRO}}
   ${OTHER_RELRO_SECTIONS}
@@ -480,13 +484,13 @@
 
   ${DATA_PLT+${PLT_BEFORE_GOT-${PLT}}}
 
-  .data          :
+  .data         ${RELOCATING-0} :
   {
     ${RELOCATING+${DATA_START_SYMBOLS}}
     *(.data${RELOCATING+ .data.* .gnu.linkonce.d.*})
     ${CONSTRUCTING+SORT(CONSTRUCTORS)}
   }
-  .data1         : { *(.data1) }
+  .data1        ${RELOCATING-0} : { *(.data1) }
   ${WRITABLE_RODATA+${RODATA}}
   ${OTHER_READWRITE_SECTIONS}
   ${SMALL_DATA_CTOR+${RELOCATING+${CTOR}}}
@@ -502,7 +506,7 @@
   ${RELOCATING+${OTHER_BSS_SYMBOLS}}
   ${SBSS}
   ${BSS_PLT+${PLT}}
-  .bss           :
+  .bss          ${RELOCATING-0} :
   {
    *(.dynbss)
    *(.bss${RELOCATING+ .bss.* .gnu.linkonce.b.*})

Revision history for this message

Zooko Wilcox-O'Hearn (zooko) wrote on 2009-10-27:

#13

I posted to the Crypto++ mailing list asking for help and warning them not to upgrade to Karmic:
http://groups.google.com/group/cryptopp-users/browse_thread/thread/36ceee8e8f500fd3

Revision history for this message

Zooko Wilcox-O'Hearn (zooko) wrote on 2009-10-27:

#14

Wei Dai, the author of Crypto++, has kindly volunteered to investigate: http://groups.google.com/group/cryptopp-users/msg/e49e6e8a0adf4630

He asks:

"How can we find out who submitted the the binutil patch and contact him or her?"

Revision history for this message

Zooko Wilcox-O'Hearn (zooko) wrote on 2009-10-27:

#15

Please also see my response where I say that I don't know where the patches come from and where I speculate about blacklisting this particular version of GNU assembler:

http://groups.google.com/group/cryptopp-users/msg/fef83f2a64c797cc

Revision history for this message

Matthias Klose (doko) wrote on 2009-10-27: Re: [Bug 461303] Re: generates-bad-code regression

#16

On 27.10.2009 16:44, Zooko O'Whielacronx wrote:
> Wei Dai, the author of Crypto++, has kindly volunteered to investigate:
> http://groups.google.com/group/cryptopp-users/msg/e49e6e8a0adf4630

did you identify the patch causing the failure?

> He asks:
>
> "How can we find out who submitted the the binutil patch and contact him
> or her?"

<email address hidden>, but it would be good to identify the relevant checkin
first. See the ChangeLog files in the various subdirectories.

Revision history for this message

In Sourceware.org Bugzilla #10856, Matthias Klose (doko) wrote on 2009-10-27:

#25

The patch to fix PR gas/10704 causes sha.cpp assembled in a way that causes the
sha-256 test not to terminate. Undoing the patch runs the test fine. Replacing
the sha.o with one assembled with gas having this patch reverted lets the test pass.

Revision history for this message

In Sourceware.org Bugzilla #10856, Matthias Klose (doko) wrote on 2009-10-27:

#26

Created attachment 4329
diff of disassembled files

Revision history for this message

In Sourceware.org Bugzilla #10856, Matthias Klose (doko) wrote on 2009-10-27:

#27

Created attachment 4330
sha .s and .o files

Changed in binutils (Ubuntu):
importance:	Undecided → Medium
status:	New → Confirmed

Revision history for this message

In Sourceware.org Bugzilla #10856, Alan Modra (amodra-gmail) wrote on 2009-10-28:

#28

Simpler testcase:

.text
.intel_syntax noprefix
.space 5480
.byte 0,0,0
0:
.space 1620
.byte 0
1:
.space 2468
nop
jne 1b
.space 52
nop
jl 0b

Without the .intel_syntax this assembles OK.

Revision history for this message

In Sourceware.org Bugzilla #10856, Cvs-commit (cvs-commit) wrote on 2009-10-28:

#29

Subject: Bug 10856

CVSROOT: /cvs/src
Module name: src
Changes by: <email address hidden> 2009-10-28 08:21:45

Modified files:
gas : ChangeLog expr.c
gas/testsuite : ChangeLog
gas/testsuite/gas/i386: intelpic.d

Log message:
PR gas/10856
* expr.c (resolve_expression): Only add "left" value to O_symbol
expression when the symbol is undefined and different from the
original symbol. Simplify negative logic.

* gas/i386/intelpic.d: Correct.

Patches:
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/gas/ChangeLog.diff?cvsroot=src&r1=1.3999&r2=1.4000
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/gas/expr.c.diff?cvsroot=src&r1=1.78&r2=1.79
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/gas/testsuite/ChangeLog.diff?cvsroot=src&r1=1.1573&r2=1.1574
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/gas/testsuite/gas/i386/intelpic.d.diff?cvsroot=src&r1=1.3&r2=1.4

Revision history for this message

In Sourceware.org Bugzilla #10856, Cvs-commit (cvs-commit) wrote on 2009-10-28:

#30

Subject: Bug 10856

CVSROOT: /cvs/src
Module name: src
Branch: binutils-2_20-branch
Changes by: <email address hidden> 2009-10-28 08:23:49

Modified files:
gas : ChangeLog expr.c

Log message:
PR gas/10856
* expr.c (resolve_expression): Only add "left" value to O_symbol
expression when the symbol is undefined and different from the
original symbol. Simplify negative logic.

Patches:
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/gas/ChangeLog.diff?cvsroot=src&only_with_tag=binutils-2_20-branch&r1=1.3938.2.27&r2=1.3938.2.28
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/gas/expr.c.diff?cvsroot=src&only_with_tag=binutils-2_20-branch&r1=1.77.2.1&r2=1.77.2.2

Revision history for this message

In Sourceware.org Bugzilla #10856, Matthias Klose (doko) wrote on 2009-10-28:

#31

checked that the sha test passes, when sha.o is built with this patch.

Revision history for this message

In Sourceware.org Bugzilla #10856, Alan Modra (amodra-gmail) wrote on 2009-10-28:

#32

.

Matthias Klose (doko) on 2009-10-28

Changed in binutils (Ubuntu Karmic):
status:	Confirmed → In Progress

Scott Kitterman (kitterman) on 2009-10-28

Changed in libcrypto++ (Ubuntu Karmic):
status:	New → Invalid
Changed in binutils (Ubuntu Karmic):
milestone:	none → karmic-updates

Revision history for this message

Martin Pitt (pitti) wrote on 2009-10-28:

#17

I reviewed the package in -proposed. Will accept right after karmic release.

What is the test case here? libcrypto++ failing the tests (and build) in karmic final, and succeeding with the proposed update?

Changed in binutils (Ubuntu Karmic):
assignee:	nobody → Matthias Klose (doko)
status:	In Progress → Fix Committed

Revision history for this message

Martin Pitt (pitti) wrote on 2009-10-29:

#18

Accepted binutils into karmic-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

tags:

added: verification-needed

Bug Watch Updater (bug-watch-updater) on 2009-10-30

Changed in binutils:
status:	Unknown → Fix Released

Revision history for this message

Matthias Klose (doko) wrote on 2009-10-30:

#19

the updated package builds libcrypto++, same fix for lucid is in 2.20-1ubuntu1, now in lucid.

Martin Pitt (pitti) on 2009-10-30

tags:	added: verification-done removed: verification-needed
Changed in binutils (Ubuntu):
status:	Fix Committed → Fix Released
milestone:	karmic-updates → none

Revision history for this message

Zooko Wilcox-O'Hearn (zooko) wrote on 2009-10-31:

#20

Confirmed on the pycryptopp buildbot: binutils 2.20-0ubuntu1: http://allmydata.org/buildbot-pycryptopp/builders/linux-amd64-ubuntu-karmic-yukyuk/builds/16 , 2.20-0ubuntu2: http://allmydata.org/buildbot-pycryptopp/builders/linux-amd64-ubuntu-karmic-yukyuk/builds/17

Bug Watch Updater (bug-watch-updater) on 2009-11-01

Changed in tahoe-lafs:
status:	Unknown → New

Revision history for this message

Martin Pitt (pitti) wrote on 2009-11-04:

#21

I built several packages with this binutils version (like udev, devicekit-disks, empathy, etc.), and they all work fine.

Revision history for this message

Launchpad Janitor (janitor) wrote on 2009-11-04:

#22

This bug was fixed in the package binutils - 2.20-0ubuntu2

---------------
binutils (2.20-0ubuntu2) karmic-proposed; urgency=low

* Fix PR gas/10856, wrong code with assembler files in intel syntax.
Patch taken from the 2.20 branch. LP: #461303.

-- Matthias Klose <email address hidden> Wed, 28 Oct 2009 09:46:50 +0100

Changed in binutils (Ubuntu Karmic):
status:	Fix Committed → Fix Released

Revision history for this message

In Sourceware.org Bugzilla #10856, Alan Modra (amodra-gmail) wrote on 2009-11-05:

#33

*** Bug 10906 has been marked as a duplicate of this bug. ***

Revision history for this message

In Red Hat Bugzilla #544358, nucleo (nucleo-redhat-bugs) wrote on 2009-12-04:

#41

Description of problem:
cryptest from cryptopp hangs up when built for fc13.
cryptest is running in %check section of cryptopp.spec, so cryptopp can't be built for fc13.
For fc12 cryptopp builds fine.

Version-Release number of selected component (if applicable):
binutils 2.20.51.0.2-8.fc13

See the same issues here:

http://sourceware.org/bugzilla/show_bug.cgi?id=10856

https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/461303

Bug Watch Updater (bug-watch-updater) on 2009-12-07

Changed in tahoe-lafs:
status:	New → Fix Released

Revision history for this message

In Red Hat Bugzilla #544358, Nick (nick-redhat-bugs) wrote on 2009-12-09:

#42

Hi Alec,

I have imported Alan Modra's patch for PR 10856 into the devel binutils rpm. Please try using the latest release (2.20.51.0.2-9), and if you still have problems, let us know.

Cheers
Nick

Revision history for this message

In Red Hat Bugzilla #544358, nucleo (nucleo-redhat-bugs) wrote on 2009-12-09:

#43

Hi Nick,

With binutils 2.20.51.0.2-9.fc13 cryptopp test not fails.

Finally cryptopp-5.6.1-0.1.svn479.fc13 built:
http://koji.fedoraproject.org/koji/buildinfo?buildID=143094

Should I close this bug?

Alexey

Revision history for this message

In Sourceware.org Bugzilla #10856, Daira Hopwood (daira) wrote on 2009-12-13:

#34

Any indication of when this fix is likely to get into a release? The more OS
distributions as 2.20 goes into, the more problems this bug will cause.

Revision history for this message

In Sourceware.org Bugzilla #10856, Zooko Wilcox-O'Hearn (zooko) wrote on 2009-12-13:

#35

This launchpad page tracks the increasing number of OS distributions and open
source projects that are being negatively affected by the bug in 2.20:

https://bugs.launchpad.net/fedora/+source/binutils/+bug/461303

Revision history for this message

In Red Hat Bugzilla #544358, Zooko (zooko-redhat-bugs) wrote on 2009-12-13:

#44

This page on launchpad is tracking the progress of this issue through several different operating systems and open source projects that are affected by this bug. I added a link to this ticket on bugzilla.redhat.com:

https://bugs.launchpad.net/fedora/+source/binutils/+bug/461303

Bug Watch Updater (bug-watch-updater) on 2009-12-13

Changed in binutils (Fedora):
status:	Unknown → In Progress

Revision history for this message

In Sourceware.org Bugzilla #10856, Gingold (gingold) wrote on 2009-12-14:

#36

Subject: Re: [2.20 regression] gas creates wrong code which results in a test failure in libcrypto++'s sha2 test

On Dec 13, 2009, at 6:55 PM, david-sarah at jacaranda dot org wrote:

>
> ------- Additional Comments From david-sarah at jacaranda dot org 2009-12-13 17:55 -------
> Any indication of when this fix is likely to get into a release? The more OS
> distributions as 2.20 goes into, the more problems this bug will cause.

I agree that this is annoying. What about a 2.20.1 release in January ?

Tristan.

Bug Watch Updater (bug-watch-updater) on 2010-01-24

Changed in pycryptopp:
status:	Unknown → Fix Released

Revision history for this message

In Red Hat Bugzilla #544358, Michal (michal-redhat-bugs) wrote on 2010-04-21:

#45

Notes: Changing version to 13 from 12, since wrt comment 0 it is clear that F-13 had that issue not F-12. Closing, we have update.

Revision history for this message

In Sourceware.org Bugzilla #10856, Zooko Wilcox-O'Hearn (zooko) wrote on 2010-07-06:

#37

Hey folks, some distributions such as MinGW have still not patched their version of binutils or reverted
to binutils 2.19:

https://sourceforge.net/tracker/index.php?func=detail&aid=2913876&group_id=2435&atid=102435

This is still causing problems for my users:

http://tahoe-lafs.org/trac/tahoe-lafs/ticket/853

If you folks could go ahead and release a binutil 2.20.1 then that might stimulate distributors like
MinGW to upgrade to it and that would fix the problem for my users. Thanks!

Revision history for this message

Zooko Wilcox-O'Hearn (zooko) wrote on 2010-07-29:

#23

Fixed in MingW's upgrade to binutils 2.20.51.20100613

Changed in mingw:
importance:	Unknown → Undecided
status:	Unknown → New
status:	New → Fix Released
importance:	Undecided → Unknown
status:	Fix Released → Unknown
importance:	Unknown → Undecided
status:	Unknown → New
importance:	Undecided → Unknown
status:	New → Unknown
importance:	Unknown → Undecided
status:	Unknown → New
importance:	Undecided → Unknown
status:	New → Unknown

Revision history for this message

In Sourceware.org Bugzilla #10856, Zooko Wilcox-O'Hearn (zooko) wrote on 2010-12-19:

#38

binutils 2.20.1, released 2010-03-03, does *not* have the ChangeLog entry from http://sourceware.org/bugzilla/show_bug.cgi?id=10856#c5 but *does* have the patch to expr.c. Weird. But I guess it is fixed in binutils 2.20.1.

Revision history for this message

Zooko Wilcox-O'Hearn (zooko) wrote on 2010-12-19:

#24

binutils 2.20.1, released 2010-03-03, does *not* have the ChangeLog entry from http://sourceware.org/bugzilla/show_bug.cgi?id=10856#c5 but *does* have the patch to expr.c. Weird. But I guess it is fixed in binutils 2.20.1.

Bug Watch Updater (bug-watch-updater) on 2011-05-26

Changed in binutils:
importance:	Unknown → Medium

Revision history for this message

Zooko Wilcox-O'Hearn (zooko) wrote on 2012-01-11:

#39

Could a "project maintainer or bug supervisor" please change the Fedora bug status from "In Progress" to "Fix Released" or authorize me to do so?

Revision history for this message

In Red Hat Bugzilla #544358, Zooko (zooko-redhat-bugs) wrote on 2012-01-11:

#46

If anybody reading this has the authority to change the status of tickets in launchpad, please mark this as fixed there: https://bugs.launchpad.net/fedora/+source/binutils/+bug/461303 . Thanks!

Revision history for this message

Zooko Wilcox-O'Hearn (zooko) wrote on 2012-01-11:

#40

Could a "project maintainer or bug supervisor" please change the MinGW bug status from "In Progress" to "Fix Released" or authorize me to do so?

Bug Watch Updater (bug-watch-updater) on 2017-10-27

Changed in binutils (Fedora):
importance:	Unknown → Medium
status:	In Progress → Fix Released

Ubuntu
binutils package

generates-bad-code regression

Bug Description

Other bug subscribers

Remote bug watches

	Status	Importance	Assigned to	Milestone
MinGW	Unknown	Unknown	sf #2913876
Tahoe-LAFS	Fix Released	Unknown	auto-allmydata.org #31
binutils	Fix Released	Medium	sourceware-bugs #10856
pycryptopp	Fix Released	Unknown	auto-allmydata.org #31
binutils (Fedora)	Fix Released	Medium	redhat-bugs #544358
binutils (Ubuntu)	Fix Released	Medium	Matthias Klose
Karmic	Fix Released	Medium	Matthias Klose	Ubuntu karmic-updates
libcrypto++ (Ubuntu)	Invalid	Undecided	Unassigned
Karmic	Invalid	Undecided	Unassigned

Ubuntubinutils package

generates-bad-code regression

Bug Description

Other bug subscribers

Remote bug watches

Ubuntu
binutils package