kde-extraapps/syndication/tests/additional/gmane.comp.gnu.binutils.xml

706 lines
28 KiB
XML

<?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>