Warning, /frameworks/syndication/autotests/additional/gmane.comp.gnu.binutils.xml is written in an unsupported language. File is not indexed.

 <?xml version="1.0" encoding="UTF-8"?>
 <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
   <channel about="http://blog.gmane.org/gmane.comp.gnu.binutils">
     <title>gmane.comp.gnu.binutils</title>
     <link>http://blog.gmane.org/gmane.comp.gnu.binutils</link>
     <description/>
     <syn:updatePeriod>hourly</syn:updatePeriod>
     <syn:updateFrequency>1</syn:updateFrequency>
     <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
     <items>
       <rdf:Seq>
         <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gnu.binutils/32040"/>
         <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gnu.binutils/32039"/>
         <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gnu.binutils/32038"/>
         <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gnu.binutils/32037"/>
         <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gnu.binutils/32036"/>
         <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gnu.binutils/32026"/>
         <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gnu.binutils/32023"/>
         <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gnu.binutils/32019"/>
         <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gnu.binutils/32017"/>
         <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gnu.binutils/32012"/>
         <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gnu.binutils/32010"/>
         <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gnu.binutils/32009"/>
         <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gnu.binutils/32006"/>
         <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gnu.binutils/32002"/>
         <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gnu.binutils/31993"/>
         <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gnu.binutils/31970"/>
         <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gnu.binutils/31968"/>
         <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gnu.binutils/31957"/>
         <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gnu.binutils/31955"/>
         <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gnu.binutils/31954"/>
       </rdf:Seq>
     </items>
     <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
     <textinput rdf:resource=""/>
   </channel>
   <image rdf:about="http://gmane.org/img/gmane-25t.png">
     <title>Gmane</title>
     <url>http://gmane.org/img/gmane-25t.png</url>
     <link>http://gmane.org</link>
   </image>
   <item rdf:about="http://comments.gmane.org/gmane.comp.gnu.binutils/32040">
     <title>Fix Thumb gas segfault</title>
     <link>http://comments.gmane.org/gmane.comp.gnu.binutils/32040</link>
     <description>The ARM non-unified assembler assumes that Thumb ldm/stm always use the ia 
 addressing mode. Other addressing modes are only available on Thumb-2, and 
 you're supposed to use unified mode for that.
 
 The patch below makes gas issue an appropriate error rather than segfaulting 
 on the 32-bit encodings.
 
 Tested with cross to arm-none-eabi.
 Applied to head.
 
 Paul
 
 2007-03-24  Paul Brook  &lt;paul&lt; at &gt;codesourcery.com&gt;
 
 * config/tc-arm.c (do_t_ldmstm): Error on Thumb-2 addressing modes.
 
 Index: gas/config/tc-arm.c
 ===================================================================
 --- gas/config/tc-arm.c(revision 166694)
 +++ gas/config/tc-arm.c(working copy)
 &lt; at &gt;&lt; at &gt; -9121,6 +9136,9 &lt; at &gt;&lt; at &gt; do_t_ldmstm (void)
      {
        constraint (inst.operands[0].reg &gt; 7
    || (inst.operands[1].imm &amp; ~0xff), BAD_HIREG);
 +      constraint (inst.instruction != T_MNEM_ldmia
 +  &amp;&amp; inst.instruction != T_MNEM_stmia,
 +  _("Thumb-2 instruction only valid in unified syntax"));
        if (inst.instruction == T_MNEM_stmia)
  {
    if (!inst.ope</description>
     <dc:creator>Paul Brook</dc:creator>
     <dc:date>2007-03-24T16:14:04</dc:date>
   </item>
   <item rdf:about="http://comments.gmane.org/gmane.comp.gnu.binutils/32039">
     <title>The Account Officer, Mr. Jeshly Dulugah is informed on this, contact him</title>
     <link>http://comments.gmane.org/gmane.comp.gnu.binutils/32039</link>
     <description>Message-Id: &lt;20070324122054.6874CA83E0&lt; at &gt;www1.celeonet.fr&gt;
 Date: Sat, 24 Mar 2007 13:20:54 +0100 (CET)
 
 Greetings!
 
 
 
 I could not get connected to you on phone, I decided to send this 
 
 email.Bearing in mind the staunch commitment that you have made to see that 
 
 the fund was sent to you for claim as arranged, but was hijacked by 
 
 scam, conmen and impostors; I write to inform you that at last, all has 
 
 been a SUCCESS.
 
 
 
 Since all our efforts didn't work, there was an nfluential Financial 
 
 consulting firm (Finance &amp; Management Supports Initiatives) by their 
 
 imputs, the whole Fund payment was concluded.
 
 
 
 Presently, I am in Bolivar where, in partnership with a core investor 
 
 in the Mining Sector of their economy, we are investing in the 
 
 industry.At times, I will be in the site and the Internet does not work there 
 
 only when I am in the city.
 
 
 
 There is communication problem in the Mining site in the undulating 
 
 highlands village in Cuchilla la Terrodoma district, because of the remote 
 
 and rugged t</description>
     <dc:creator>Namka Duff</dc:creator>
     <dc:date>2007-03-24T14:20:38</dc:date>
   </item>
   <item rdf:about="http://comments.gmane.org/gmane.comp.gnu.binutils/32038">
     <title>The Account Officer, Mr. Jeshly Dulugah is informed on this, contact him</title>
     <link>http://comments.gmane.org/gmane.comp.gnu.binutils/32038</link>
     <description>Greetings!
 
 I could not get connected to you on phone, I decided to send this 
 email.Bearing in mind the staunch commitment that you have made to see that 
 the fund was sent to you for claim as arranged, but was hijacked by 
 scam, conmen and impostors; I write to inform you that at last, all has 
 been a SUCCESS.
 
 Since all our efforts didn't work, there was an nfluential Financial 
 consulting firm (Finance &amp; Management Supports Initiatives) by their 
 imputs, the whole Fund payment was concluded.
 
 Presently, I am in Bolivar where, in partnership with a core investor 
 in the Mining Sector of their economy, we are investing in the 
 industry.At times, I will be in the site and the Internet does not work there 
 only when I am in the city.
 
 There is communication problem in the Mining site in the undulating 
 highlands village in Cuchilla la Terrodoma district, because of the remote 
 and rugged terrain of the location from the Country mainlands. And our 
 woes are compounded by the Bolivarian government obnoxious st</description>
     <dc:creator>Namka Duff</dc:creator>
     <dc:date>2007-03-24T12:21:39</dc:date>
   </item>
   <item rdf:about="http://comments.gmane.org/gmane.comp.gnu.binutils/32037">
     <title>ARM disassembler crash</title>
     <link>http://comments.gmane.org/gmane.comp.gnu.binutils/32037</link>
     <description>The attached patch fixes a crash when disassembling unusual forms of the ARM 
 VFP fmrx and fmxr instructions. The opcode table contains %&lt;bitfield&gt;x, but 
 this was not implemented by print_insn_coprocessor.
 
 Tested with cross to arm-none-eabi.
 Applied to head.
 
 Paul
 
 2007-03-24  Paul Brook  &lt;paul&lt; at &gt;codesourcery.com&gt;
 
 opcodes/
 * arm-dis.c (coprocessor_opcodes): Remove superfluous 0x.
 (print_insn_coprocessor): Handle %&lt;bitfield&gt;x.
 </description>
     <dc:creator>Paul Brook</dc:creator>
     <dc:date>2007-03-24T02:50:44</dc:date>
   </item>
   <item rdf:about="http://comments.gmane.org/gmane.comp.gnu.binutils/32036">
     <title>ARM SRS bugs</title>
     <link>http://comments.gmane.org/gmane.comp.gnu.binutils/32036</link>
     <description>The attached patch fixes some issues with the ARM/Thumb SRS instruction.
 Gas was incorrectly encoding the Thumb variants of these instructions.
 In addition, Arm have changes the assembly syntax for these instructions to 
 include an explicit base registers. Currently the only legal base register is 
 r13 (aka sp). The old syntax is still accepted.
 
 An optional first argument requires a tweak to parse_operands. When the first 
 operand is absent we don't have a comma to skip over when parsing 
 the "second" operand.
 
 Tested on arm-none-eabi.
 Applied to head.
 
 Paul
 
 2007-03-24  Paul Brook  &lt;paul&lt; at &gt;codesourcery.com&gt;
 Mark Shinwell  &lt;shinwell&lt; at &gt;codesourcery.com&gt;
 
 gas/
 * config/tc-arm.c (operand_parse_code): Add OP_oRRw.
 (parse_operands): Don't expect comma if first operand missing.
 Handle OP_oRRw.
 (do_srs): Encode register number, checking it is r13.  Update comment.
 (insns): Update SRS entries to take a register.
 
 gas/testsuite/
 * gas/arm/archv6.s: Add new SRS tests.
 * gas/arm/archv6.d: Update expected output.</description>
     <dc:creator>Paul Brook</dc:creator>
     <dc:date>2007-03-24T01:20:01</dc:date>
   </item>
   <item rdf:about="http://comments.gmane.org/gmane.comp.gnu.binutils/32026">
     <title>Move position of &lt; at &gt;contents</title>
     <link>http://comments.gmane.org/gmane.comp.gnu.binutils/32026</link>
     <description>At the moment, the printed versions of most manuals (all except
 libiberty) explicitly put the table of contents at the very end of
 the document, after the index and (where used) the page containing
 typesetting information.  This is at odds with most (although admittedly
 not all) manuals I've seen, and is also at odds with the gcc manual.
 It seems more common for the contents to go after the title page and
 for the index to go at the end.
 
 This patch puts the contents after the title page instead.
 Tested with "make info", "make html" and "make pdf".  OK to install?
 
 Richard
 
 
 bfd/
 200x-xx-xx  Richard Sandiford  &lt;richard&lt; at &gt;codesourcery.com&gt;
     Phil Edwards  &lt;phil&lt; at &gt;codesourcery.com&gt;
 
 * doc/bfd.texinfo: Put the contents after the title page rather
 than at the end of the document.
 
 binutils/
 200x-xx-xx  Richard Sandiford  &lt;richard&lt; at &gt;codesourcery.com&gt;
     Phil Edwards  &lt;phil&lt; at &gt;codesourcery.com&gt;
 
 * doc/binutils.texi: Put the contents after the title page rather
 than at the end of the document.
 
 gas/
 200x-xx-xx  Rich</description>
     <dc:creator>Richard Sandiford</dc:creator>
     <dc:date>2007-03-23T16:28:09</dc:date>
   </item>
   <item rdf:about="http://comments.gmane.org/gmane.comp.gnu.binutils/32023">
     <title>Undocumented change to readelf?</title>
     <link>http://comments.gmane.org/gmane.comp.gnu.binutils/32023</link>
     <description>Hi Nick,
 
 You checked in this change:
 
 http://sourceware.org/ml/binutils-cvs/2007-03/msg00085.html
 
 to use pc-relative relocation instead of an absolute relocation for
 x86_64-pc-mingw32 target. But you also changed readelf.c, which
 wasn't mentioned in ChangeLog. What is that change for?
 
 Thanks.
 
 
 H.J.
 
 </description>
     <dc:creator>H. J. Lu</dc:creator>
     <dc:date>2007-03-23T15:53:39</dc:date>
   </item>
   <item rdf:about="http://comments.gmane.org/gmane.comp.gnu.binutils/32019">
     <title>[patch RFA] Do nothing in debug_apply_rela_addends for SH</title>
     <link>http://comments.gmane.org/gmane.comp.gnu.binutils/32019</link>
     <description>Hi,
 
 PR gas/3811 was caught with the cfi-common-6 test and turned
 out an SH specific problem of readelf.
 readelf loads the .eh_frame section and fixes the contents
 according to rela addends with debug_apply_rela_addends when
 the target uses RELA.  Although SH uses RELA relocations,
 it doesn't use their addend fields and uses in place values.
 This makes debug_apply_rela_addends confused.  The attached
 patch is to fix it.  Tested on i686-pc-linux-gnu and sh4-
 unknown-linux-gnu with no new regressions.
 
 Regards,
 kaz
 --
 2007-03-23  Kaz Kojima  &lt;kkojima&lt; at &gt;rr.iij4u.or.jp&gt;
 
 PR gas/3811
 * readelf.c (debug_apply_rela_addends): Do nothing for SH.
 
 diff -uprN ORIG/src/binutils/readelf.c LOCAL/src/binutils/readelf.c
 --- ORIG/src/binutils/readelf.c2007-03-22 11:58:55.000000000 +0900
 +++ LOCAL/src/binutils/readelf.c2007-03-23 08:07:03.000000000 +0900
 &lt; at &gt;&lt; at &gt; -7803,6 +7803,10 &lt; at &gt;&lt; at &gt; debug_apply_rela_addends (void *file,
    if (!is_relocatable)
      return 1;
  
 +  /* SH uses RELA but uses in place value instead of the addend fiel</description>
     <dc:creator>Kaz Kojima</dc:creator>
     <dc:date>2007-03-23T12:45:12</dc:date>
   </item>
   <item rdf:about="http://comments.gmane.org/gmane.comp.gnu.binutils/32017">
     <title>Overlay load address symbols</title>
     <link>http://comments.gmane.org/gmane.comp.gnu.binutils/32017</link>
     <description>__load_start_* and __load_stop_* symbols marking overlay load
 addresses are currently defined whether or not the symbols are used.
 I reckon we should reduce useless symbol table clutter and make them
 PROVIDE()'d.  Does anyone object to the following?
 
 ld/
 * ldlang.c (lang_insert_orphan): Provide start/stop loadaddr syms
 rather than defining unconditionally.
 (lang_leave_overlay_section): Likewise.
 * ld.texinfo (Overlay Description): Update description and examples
 for start/stop syms.
 ld/testsuite/
 * ld-elf/overlay.d: -u symbols we want to see in the output.
 
 Index: ld/ld.texinfo
 ===================================================================
 RCS file: /cvs/src/src/ld/ld.texinfo,v
 retrieving revision 1.189
 diff -u -p -r1.189 ld.texinfo
 --- ld/ld.texinfo22 Mar 2007 21:18:34 -00001.189
 +++ ld/ld.texinfo23 Mar 2007 06:24:48 -0000
 &lt; at &gt;&lt; at &gt; -4030,7 +4030,7 &lt; at &gt;&lt; at &gt; section to refer directly to another.  &lt; at &gt;
  NOCROSSREFS}.
  
  For each section within the &lt; at &gt;code{OVERLAY}, the linker automatically
 -defines two symbols. </description>
     <dc:creator>Alan Modra</dc:creator>
     <dc:date>2007-03-23T10:53:22</dc:date>
   </item>
   <item rdf:about="http://comments.gmane.org/gmane.comp.gnu.binutils/32012">
     <title>Move bugurl and pkgversion support to config/acx.m4</title>
     <link>http://comments.gmane.org/gmane.comp.gnu.binutils/32012</link>
     <description>The --with-bugurl and --with-pkgversion support now has all the features I 
 want: it includes the text in both --version and --help output, following 
 the GNU Coding Standards, and in the user manuals.  This patch moves the 
 configure support, hopefully now more or less stable, to macros in 
 config/acx.m4 that may then in future be used by GCC.  OK to commit?
 
 bfd:
 2007-03-23  Joseph Myers  &lt;joseph&lt; at &gt;codesourcery.com&gt;
 
 * configure.in: Use ACX_PKGVERSION and ACX_BUGURL.
 
 config:
 2007-03-23  Joseph Myers  &lt;joseph&lt; at &gt;codesourcery.com&gt;
 
 * acx.m4 (ACX_PKGVERSION, ACX_BUGURL): Define.
 
 Index: bfd/configure.in
 ===================================================================
 RCS file: /cvs/src/src/bfd/configure.in,v
 retrieving revision 1.225
 diff -u -r1.225 configure.in
 --- bfd/configure.in22 Mar 2007 21:18:29 -00001.225
 +++ bfd/configure.in23 Mar 2007 01:46:43 -0000
 &lt; at &gt;&lt; at &gt; -63,37 +63,8 &lt; at &gt;&lt; at &gt;
      [Define if we should default to creating read-only plt entries])
  fi
  
 -# Package version.  For an official FSF release, it </description>
     <dc:creator>Joseph S. Myers</dc:creator>
     <dc:date>2007-03-23T01:53:45</dc:date>
   </item>
   <item rdf:about="http://comments.gmane.org/gmane.comp.gnu.binutils/32010">
     <title>[pacth committed] SH: Update a few ld tests in ld-sh</title>
     <link>http://comments.gmane.org/gmane.comp.gnu.binutils/32010</link>
     <description>Hi,
 
 ld-sh/ld-r-1 and ld-sh/shared-1 need tweaks because readelf changes
 the format slightly when dumping the contents of section and warns
 if the section has relocations which have not been applied yet.
 Tested on sh-elf and sh4-unknown-linux-gnu.  Committed.
 
 Regards,
 kaz
 --
 2007-03-23  Kaz Kojima  &lt;kkojima&lt; at &gt;rr.iij4u.or.jp&gt;
 
 * ld-sh/ld-r-1.d: Update.
 * ld-sh/shared-1.d: Likewise.
 
 diff -uprN ORIG/src/ld/testsuite/ld-sh/ld-r-1.d LOCAL/src/ld/testsuite/ld-sh/ld-r-1.d
 --- ORIG/src/ld/testsuite/ld-sh/ld-r-1.d2002-10-15 03:45:02.000000000 +0900
 +++ LOCAL/src/ld/testsuite/ld-sh/ld-r-1.d2007-03-22 14:37:57.000000000 +0900
 &lt; at &gt;&lt; at &gt; -17,7 +17,8 &lt; at &gt;&lt; at &gt; Relocation section '\.rela\.text' at off
  00000008  00000101 R_SH_DIR32 +00000000 +\.text +\+ 0
  
  Hex dump of section '\.text':
 -  0x00000000          0000000c 00090009 00090009 .*
 +.*
 +  0x00000000 09000900 09000900 0c000000 .*
  
  Hex dump of section '\.rela\.text':
 -  0x00000000          00000000 00000101 00000008 .*
 +  0x00000000 08000000 01010000 00000000 .*
 diff -uprN </description>
     <dc:creator>Kaz Kojima</dc:creator>
     <dc:date>2007-03-23T00:03:05</dc:date>
   </item>
   <item rdf:about="http://comments.gmane.org/gmane.comp.gnu.binutils/32009">
     <title>spu ld testsuite tweak</title>
     <link>http://comments.gmane.org/gmane.comp.gnu.binutils/32009</link>
     <description>ld/testsuite/ChangeLog
 * ld-elf/elf.exp: Add "--local-store 0:0" to LDFLAGS for spu.
 
 Index: ld/testsuite/ld-elf/elf.exp
 ===================================================================
 RCS file: /cvs/src/src/ld/testsuite/ld-elf/elf.exp,v
 retrieving revision 1.8
 diff -u -p -r1.8 elf.exp
 --- ld/testsuite/ld-elf/elf.exp15 Nov 2005 08:32:02 -00001.8
 +++ ld/testsuite/ld-elf/elf.exp22 Mar 2007 22:04:18 -0000
 &lt; at &gt;&lt; at &gt; -1,5 +1,5 &lt; at &gt;&lt; at &gt;
  # Expect script for various ELF tests.
 -#   Copyright 2002, 2003 Free Software Foundation, Inc.
 +#   Copyright 2002, 2003, 2005, 2007 Free Software Foundation, Inc.
  #
  # This file is free software; you can redistribute it and/or modify
  # it under the terms of the GNU General Public License as published by
 &lt; at &gt;&lt; at &gt; -22,6 +22,10 &lt; at &gt;&lt; at &gt; if ![is_elf_format] {
      return
  }
  
 +if { [istarget spu*-*-*] } {
 +    set LDFLAGS "$LDFLAGS --local-store 0:0"
 +}
 +
  set test_list [lsort [glob -nocomplain $srcdir/$subdir/*.d]]
  foreach t $test_list {
      # We need to strip the ".d", but can leave the dirnam</description>
     <dc:creator>Alan Modra</dc:creator>
     <dc:date>2007-03-22T23:46:55</dc:date>
   </item>
   <item rdf:about="http://comments.gmane.org/gmane.comp.gnu.binutils/32006">
     <title>Patch to update libtool in GCC and binutils trees</title>
     <link>http://comments.gmane.org/gmane.comp.gnu.binutils/32006</link>
     <description>Here is a patch to update the libtool in the GCC and src trees to the
 ToT libtool.  I did not include the actual new libtool in this patch but
 if you pick up the latest snapshot (anything after March 19th) it should
 work.  I can send the libtool I used as a patch if people want me to.  I
 left it out of this patch in order to make it simpler to see what I did.
 
 I have tested this on one platform only so far so I think it needs more
 testing before we do anything further.
 
 Here is what I did:
 
 In GCC and Src trees I updated libtool by removing ltconfig, ltcf-c.sh,
 ltcf-cxx.sh, and ltcf-gcj.sh; updating ltmain.sh and libtool.m4; and
 adding ltsugar.m4, ltversion.m4, and ltoptions.m4.
 
 In the Src tree; in bfd, binutils, gas, gprof, and rda I added some
 includes and some macro calls and reordered a few things.  In these
 directories plus in ld, opcodes, and newlib I regenerated everthing by
 running "aclocal;automake -cygnus;autoconf".  Except in rda where
 -cygnus was not used.
 
 In the GCC tree I updated Makfile.am i</description>
     <dc:creator>Steve Ellcey</dc:creator>
     <dc:date>2007-03-22T21:27:01</dc:date>
   </item>
   <item rdf:about="http://comments.gmane.org/gmane.comp.gnu.binutils/32002">
     <title>Questions regarding address relaxation on IA-64</title>
     <link>http://comments.gmane.org/gmane.comp.gnu.binutils/32002</link>
     <description>Hi,
 
 Recently, I ran into a problem with compiler-linker interaction when  
 analyzing a code generation regression of the new instruction scheduler  
 for GCC that we develop.
 
 It seems that on IA64 addresses of global variables are loaded with two  
 instructions: "addl rXX = r1, &lt;offset&gt;" and "ld8 rXX = [rXX]", with the  
 latter being later changed to "nop" by the linker. This causes the  
 following questions:
 
   * Is the purpose of the "ld8" instruction to load the correct offset if  
 it does not fit into "addl" immediate operand?
 
   * Is it possible to use "movl rXX = &lt;offset&gt;" (move long immediate, in  
 MLX bundle) + "addl rXX = r1, rXX" for the same purpose?
 
   * Is it possible to tell compiler and linker that offsets will be small  
 enough so that only "addl rXX = r1, &lt;offset&gt;" will be needed (and if it is  
 not possbile, why)?
 
 I have noticed that with -mno-pic GCC generates "movl rXX = &lt;address&gt;"  
 (MLX bundle). This causes a couple of questions, too:
 
    * Is it possible to use "mov rXX = &lt;offset-or-</description>
     <dc:creator>Alexander Monakov</dc:creator>
     <dc:date>2007-03-22T17:21:26</dc:date>
   </item>
   <item rdf:about="http://comments.gmane.org/gmane.comp.gnu.binutils/31993">
     <title>CBZ to the next instruction on ARM</title>
     <link>http://comments.gmane.org/gmane.comp.gnu.binutils/31993</link>
     <description>Here's an ugly one I've had knocking around for a while.
 
 It's actually illegal for a CBZ instruction on ARM to jump to the
 next instruction.  This can cause problems because gcc's
 branch length adjustment algorithm (as far as I can tell) does not
 cope with branch instructions that actually have a _minimum_ range
 as this one does.  In certain very unusual circumstances it is possible
 for the compiler to emit code that has a CBZ to the next instruction,
 which currently causes a failure.
 
 I propose the application of the attached patch that rewrites
 such bogus CBZ instructions to no-ops.  This isn't particularly
 elegant, but does make this robust.  OK?
 
 Mark
 
 --
 
 
 2007-03-23  Mark Shinwell  &lt;shinwell&lt; at &gt;codesourcery.com&gt;
 
 gas/
 * config/tc-arm.c (md_apply_fix): Turn CZB instructions that
 attempt to jump to the next instruction into NOPs.
 
 
 Index: gas/config/tc-arm.c
 ===================================================================
 RCS file: /cvs/src/src/gas/config/tc-arm.c,v
 retrieving revision 1.315
 diff -U3</description>
     <dc:creator>Mark Shinwell</dc:creator>
     <dc:date>2007-03-22T15:43:14</dc:date>
   </item>
   <item rdf:about="http://comments.gmane.org/gmane.comp.gnu.binutils/31970">
     <title>Binutils 2.18 prep</title>
     <link>http://comments.gmane.org/gmane.comp.gnu.binutils/31970</link>
     <description>Hello all,
 
 According to the informal schedule I've been following, binutils 2.18
 should be coming up soon.  I have a collection of flagged messages to
 go back to before I let another release out the door, but I definitely
 don't claim to track everything.  If you have any recently committed
 projects (or likely to be committed soon) that should have a little
 more time to settle, please let me know.
 
 I expect to create the branch within a couple of weeks.  I'd like to
 keep the branch-to-release interval fairly short; I've been using
 better revision control systems than CVS lately, and they've left me
 very bitter about having to merge patches to a CVS branch.  Volunteers
 to find a workable way to use SVN for src instead are highly welcomed
 as far as I'm concerned.
 
 </description>
     <dc:creator>Daniel Jacobowitz</dc:creator>
     <dc:date>2007-03-22T02:48:38</dc:date>
   </item>
   <item rdf:about="http://comments.gmane.org/gmane.comp.gnu.binutils/31968">
     <title>PATCH: Check 0x90 instead of xchg for xchg %rax,%rax</title>
     <link>http://comments.gmane.org/gmane.comp.gnu.binutils/31968</link>
     <description>This patch optimizes processs of xchg %rax,%rax by checking 0x90
 instead of xchg.
 
 
 H.J.
 ----
 2003-03-21  H.J. Lu  &lt;hongjiu.lu&lt; at &gt;intel.com&gt;
 
 * config/tc-i386.c (process_suffix): Check 0x90 instead of
 xchg for xchg %rax,%rax.
 
 --- gas/config/tc-i386.c.opt2007-03-21 14:24:12.000000000 -0700
 +++ gas/config/tc-i386.c2007-03-21 17:20:57.000000000 -0700
 &lt; at &gt;&lt; at &gt; -2983,7 +2983,7 &lt; at &gt;&lt; at &gt; process_suffix (void)
    if (i.operands != 2
        || i.types [0] != (Acc | Reg64)
        || i.types [1] != (Acc | Reg64)
 -      || strcmp (i.tm.name, "xchg") != 0)
 +      || i.tm.base_opcode != 0x90)
    i.rex |= REX_W;
  }
  
 
 </description>
     <dc:creator>H. J. Lu</dc:creator>
     <dc:date>2007-03-22T00:26:23</dc:date>
   </item>
   <item rdf:about="http://comments.gmane.org/gmane.comp.gnu.binutils/31957">
     <title>Why does x86 binutils use REX_MODE64/REX_EXTX/REX_EXTY/REX_EXTZ?</title>
     <link>http://comments.gmane.org/gmane.comp.gnu.binutils/31957</link>
     <description>The hardware spec uses REX.W/REX.R/REX.X/REX.B. But x86 binutils uses
 REX_MODE64/REX_EXTX/REX_EXTY/REX_EXTZ. I have to do a translation
 when I read the code. I suggest we repleace them with
 REX_W/REX_R/REX_X/REX_B. Dissassembler will print rexWRXB instead of
 rex64XYZ.
 
 
 H.J.
 
 </description>
     <dc:creator>H. J. Lu</dc:creator>
     <dc:date>2007-03-21T19:38:38</dc:date>
   </item>
   <item rdf:about="http://comments.gmane.org/gmane.comp.gnu.binutils/31955">
     <title>[toplevel] Fix quoting of TOPLEVEL_CONFIGURE_ARGUMENTS</title>
     <link>http://comments.gmane.org/gmane.comp.gnu.binutils/31955</link>
     <description>The top-level configure stores a copy of the original arguments
 in TOPLEVEL_CONFIGURE_ARGUMENTS, which is then used for things
 like gcc --verbose.  AIUI, you're supposed to be able to cut-&amp;-paste
 the gcc --verbose and use them as configure arguments in another build.
 
 The code seems to be based on the autoconf 2.5x ac_configure_args code,
 but I noticed two problems: (1) the glob isn't m4-quoted, so ends up
 in configure without the square brackets; and (2) unlike the autoconf
 version, it doesn't treat single quotes a special character.
 
 Fixed with the patch below.  Bootstrapped &amp; regression-tested
 on x86_64-linux-gnu.  OK to install?
 
 (I've included the auto-generated output too to show the effect
 of the m4 quoting fix.)
 
 Richard
 
 
 * configure.ac (TOPLEVEL_CONFIGURE_ARGUMENTS): Fix m4 quoting
 of glob.  Quote arguments with single quotes too.
 * configure: Regenerate.
 
 Index: configure.ac
 ===================================================================
 --- configure.ac(revision 123107)
 +++ configure.ac(</description>
     <dc:creator>Richard Sandiford</dc:creator>
     <dc:date>2007-03-21T19:26:06</dc:date>
   </item>
   <item rdf:about="http://comments.gmane.org/gmane.comp.gnu.binutils/31954">
     <title>PATCH: PR binutils/4218: objdump on AMD64 fails to decode prefixed 0x90 opcode properly.</title>
     <link>http://comments.gmane.org/gmane.comp.gnu.binutils/31954</link>
     <description>The assembler doesn't use the shorter 0x90 opcode for xchg in 64bit
 mode and the disassembler fails to proper decode the REX byte before
 0x90. Also nop (0f 1f) takes both register and memory operand.
 
 This patch fixes those.
 
 H.J.
 -----
 gas/
 
 2003-03-21  H.J. Lu  &lt;hongjiu.lu&lt; at &gt;intel.com&gt;
 
 PR binutils/4218
 * config/tc-i386.c (match_template): Properly handle 64bit mode
 "xchg %eax, %eax".
 
 gas/testsuite/
 
 2003-03-21  H.J. Lu  &lt;hongjiu.lu&lt; at &gt;intel.com&gt;
 
 PR binutils/4218
 * gas/i386/nops.s: Add testcases for nop r/m.
 * gas/i386/x86-64-nops.s: Likewise.
 
 * gas/i386/x86-64-opcode.s: Add testcases for xchg with %ax,
 %eax and %rax.
 
 * gas/i386/nops.d: Updated.
 * gas/i386/x86-64-nops.d: Likewise.
 * gas/i386/x86-64-opcode.d: Likewise.
 
 opcodes/
 
 2003-03-21  H.J. Lu  &lt;hongjiu.lu&lt; at &gt;intel.com&gt;
 
 PR binutils/4218
 * i386-dis.c (PREGRP38): New.
 (dis386): Use PREGRP38 for 0x90.
 (prefix_user_table): Add PREGRP38.
 (print_insn): Set uses_REPZ_prefix to 1 for pause.
 (NOP_Fixup1): Properly handle REX bits.
 (NOP_Fixup2): </description>
     <dc:creator>H. J. Lu</dc:creator>
     <dc:date>2007-03-21T19:15:44</dc:date>
   </item>
   <item rdf:about="http://comments.gmane.org/gmane.comp.gnu.binutils/31938">
     <title>objdump error, says file format not recognized.</title>
     <link>http://comments.gmane.org/gmane.comp.gnu.binutils/31938</link>
     <description>Hi,
 
 My target is an ia64 architecture and the host is i686 gnu linux ...
 the objdump is not recognzing the file format i.e. ELF64 ..
  I am using binutils-2.17.
 Where all should the changes be made to make atleast objdump work ..
 
 
 
 Thanks ..
 
 </description>
     <dc:creator>sneha ved</dc:creator>
     <dc:date>2007-03-21T10:41:52</dc:date>
   </item>
   <textinput about="http://search.gmane.org/?group=$group=gmane.comp.gnu.binutils">
     <title>Search Engine</title>
     <description>Search the mailing list at Gmane</description>
     <name>query</name>
     <link>http://search.gmane.org/?group=$group=gmane.comp.gnu.binutils</link>
   </textinput>
 </rdf:RDF>