<?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 rdf: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/57732"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gnu.binutils/57731"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gnu.binutils/57728"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gnu.binutils/57727"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gnu.binutils/57724"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gnu.binutils/57720"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gnu.binutils/57718"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gnu.binutils/57712"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gnu.binutils/57702"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gnu.binutils/57701"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gnu.binutils/57698"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gnu.binutils/57697"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gnu.binutils/57693"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gnu.binutils/57687"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gnu.binutils/57685"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gnu.binutils/57684"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gnu.binutils/57679"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gnu.binutils/57677"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gnu.binutils/57676"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gnu.binutils/57670"/>
      </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/57732">
    <title>PATCH: PR ld/14170: ld: assertion fail bfd/linker.c:641</title>
    <link>http://comments.gmane.org/gmane.comp.gnu.binutils/57732</link>
    <description>&lt;pre&gt;Hi,

We should use newdef to check new undefined symbol.  In this case,
common symbol is treated as undefined.  OK to install?

Thanks.


H.J.
----
bfd/

2012-05-26  H.J. Lu  &amp;lt;hongjiu.lu&amp;lt; at &amp;gt;intel.com&amp;gt;

PR ld/14170
* elflink.c (_bfd_elf_merge_symbol): Use newdef to check new
undefined symbol.

ld/testsuite/

2012-05-26  H.J. Lu  &amp;lt;hongjiu.lu&amp;lt; at &amp;gt;intel.com&amp;gt;

PR ld/14170
* ld-elf/elf.exp: Add a test for PR ld/14170.

* ld-elf/pr14170a.s: New file.
* ld-elf/pr14170b.s: Likewise.
* ld-elf/pr14170b.s: Likewise.

diff --git a/bfd/elflink.c b/bfd/elflink.c
index 7f35e7f..adc0a67 100644
--- a/bfd/elflink.c
+++ b/bfd/elflink.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -1217,7 +1217,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; _bfd_elf_merge_symbol (bfd *abfd,
 }
 
       if ((h-&amp;gt;root.u.undef.next || info-&amp;gt;hash-&amp;gt;undefs_tail == &amp;amp;h-&amp;gt;root)
-  &amp;amp;&amp;amp; bfd_is_und_section (sec))
+  &amp;amp;&amp;amp; !newdef)
 {
   /* If the new symbol is undefined and the old symbol was
      also undefined before, we need to make sure
diff --git a/ld/testsuite/ld-elf/elf.exp b/ld/testsuite/ld-elf/elf.exp
index eb909bc..f14498f 1006&lt;/pre&gt;</description>
    <dc:creator>H.J. Lu</dc:creator>
    <dc:date>2012-05-26T14:59:37</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gnu.binutils/57731">
    <title>Display some optimisations when --traditional-format</title>
    <link>http://comments.gmane.org/gmane.comp.gnu.binutils/57731</link>
    <description>&lt;pre&gt;How do you all feel about disabling string merging when ld is given
--traditional-format?  I think it's a reasonable addition to the
option's effect, currently it disables .stab and .eh_frame
optimisation.

The reason I'm proposing this is that I was investigating Fedora
powerpc64 binutils testsuite failures, most of which were LTO tests
that just need to be tweaked to accept "D" as well as "T" for
powerpc64 function symbols.  The other slightly more interesting
failures were the S-record tests.  They were failing because .opd
optimisation doesn't happen when ld produces srec output.  Easily
fixed by adding -no-opd-optimize to the test flags, and then the tests
pass.  However, I looked again at linker map output differences for
normal ELF output vs. srec output, and saw

&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -112,11 +108,10 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt;
                 0x00000000000010dc                PROVIDE (_etext, .)
                 0x00000000000010dc                PROVIDE (etext, .)
 
-.rodata         0x00000000000010e0       0x18
+.rodata         0x0000000000&lt;/pre&gt;</description>
    <dc:creator>Alan Modra</dc:creator>
    <dc:date>2012-05-26T11:16:31</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gnu.binutils/57728">
    <title>Simple bug fix in gold linker.</title>
    <link>http://comments.gmane.org/gmane.comp.gnu.binutils/57728</link>
    <description>&lt;pre&gt;Hi,

   Patch ok? This was causing an uninitialized variable error while building.

* symtab.cc (Symbol_table::add_undefined_symbol_from_command_line):
Initialize oldsym to prevent uninitialized variable errors.

  Index: symtab.cc
===================================================================
RCS file: /cvs/src/src/gold/symtab.cc,v
retrieving revision 1.165
diff -u -u -p -r1.165 symtab.cc
--- symtab.cc22 May 2012 23:50:52 -00001.165
+++ symtab.cc25 May 2012 21:40:38 -0000
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -2345,7 +2345,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; Symbol_table::add_undefined_symbol_from_
   const char* version = NULL;

   Sized_symbol&amp;lt;size&amp;gt;* sym;
-  Sized_symbol&amp;lt;size&amp;gt;* oldsym;
+  Sized_symbol&amp;lt;size&amp;gt;* oldsym = NULL;
   bool resolve_oldsym;
   if (parameters-&amp;gt;target().is_big_endian())
     {


Thanks,
-Sri.

&lt;/pre&gt;</description>
    <dc:creator>Sriraman Tallam</dc:creator>
    <dc:date>2012-05-25T21:42:56</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gnu.binutils/57727">
    <title>PATCH: Don't use dynamic_sec_flags on PLT .eh_frame section</title>
    <link>http://comments.gmane.org/gmane.comp.gnu.binutils/57727</link>
    <description>&lt;pre&gt;Hi,

I checked in this patch not to use ynamic_sec_flags to create PLT
.eh_frame section.

H.J.
---
diff --git a/bfd/ChangeLog b/bfd/ChangeLog
index 2165cd8..9834aab 100644
--- a/bfd/ChangeLog
+++ b/bfd/ChangeLog
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -1,3 +1,9 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt;
+2012-05-25  H.J. Lu  &amp;lt;hongjiu.lu&amp;lt; at &amp;gt;intel.com&amp;gt;
+
+* elf32-i386.c (elf_i386_create_dynamic_sections): Don't use
+dynamic_sec_flags to create PLT .eh_frame section.
+* elf64-x86-64.c (elf_x86_64_create_dynamic_sections): Likewise.
+
 2012-05-25  Alan Modra  &amp;lt;amodra&amp;lt; at &amp;gt;gmail.com&amp;gt;
 
 PR ld/13909
diff --git a/bfd/elf32-i386.c b/bfd/elf32-i386.c
index 7b33d77..6aa386d 100644
--- a/bfd/elf32-i386.c
+++ b/bfd/elf32-i386.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -1018,12 +1018,11 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; elf_i386_create_dynamic_sections (bfd *dynobj, struct bfd_link_info *info)
       &amp;amp;&amp;amp; htab-&amp;gt;plt_eh_frame == NULL
       &amp;amp;&amp;amp; htab-&amp;gt;elf.splt != NULL)
     {
-      flagword flags = get_elf_backend_data (dynobj)-&amp;gt;dynamic_sec_flags;
+      flagword flags = (SEC_ALLOC | SEC_LOAD | SEC_READONLY
+| SEC_HAS_CONTENTS | SEC_IN_MEMORY
+| SEC_LINKER_CREATED);&lt;/pre&gt;</description>
    <dc:creator>H.J. Lu</dc:creator>
    <dc:date>2012-05-25T16:20:57</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gnu.binutils/57724">
    <title>RFA: always close fd if bfd_fopen fails</title>
    <link>http://comments.gmane.org/gmane.comp.gnu.binutils/57724</link>
    <description>&lt;pre&gt;Currently, bfd_fopen has confused error handling.

If the caller passes in a file descriptor, then on any error exit before
fdopen is called, the fd will be left open; but on any error exit after
fdopen is called, the fd will be closed.

This patch changes bfd_fopen to always close the fd on error.

I audited all callers of bfd_fopen and bfd_fdopen in gdb, binutils, and
ld and fixed them not to close the fd on error.  There was only one call
outside of gdb, in ar.c, and it immediately calls bfd_fatal, and so does
not need a change.

Ok?

Tom

b/bfd/ChangeLog:
2012-05-25  Tom Tromey  &amp;lt;tromey&amp;lt; at &amp;gt;redhat.com&amp;gt;

* opncls.c (bfd_fopen): Always close fd on failure.
(bfd_fdopenr): Likewise.

b/gdb/ChangeLog:
2012-05-25  Tom Tromey  &amp;lt;tromey&amp;lt; at &amp;gt;redhat.com&amp;gt;

* symfile.c (symfile_bfd_open): Don't close desc if bfd_fopen
fails.
* solib.c (solib_bfd_fopen): Don't close fd if bfd_fopen fails.
* exec.c (exec_file_attach): Don't close scratch_chan if bfd_fopen
fails.
* dwarf2read.c (try_open_dwo_file): Don't close fd if bfd&lt;/pre&gt;</description>
    <dc:creator>Tom Tromey</dc:creator>
    <dc:date>2012-05-25T13:52:11</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gnu.binutils/57720">
    <title>Binutils bug with -Wl,--relax</title>
    <link>http://comments.gmane.org/gmane.comp.gnu.binutils/57720</link>
    <description>&lt;pre&gt;Hi Richard,

I began testing gcc-4.7.0 today on alpha and remembered that &amp;gt;=gcc-4.6
cannot build itself on alpha without passing -Wl,--no-relax.

See http://sources.redhat.com/bugzilla/show_bug.cgi?id=5276

We (Gentoo) have work-arounds in place for a number of large projects.

Can you offer any insight or assistance?

Thanks,
Matt

&lt;/pre&gt;</description>
    <dc:creator>Matt Turner</dc:creator>
    <dc:date>2012-05-25T02:07:50</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gnu.binutils/57718">
    <title>lns-big-delta gas test</title>
    <link>http://comments.gmane.org/gmane.comp.gnu.binutils/57718</link>
    <description>&lt;pre&gt;gas/lns/lns-big-delta has been failing on xtensa (the only target to
run this test) since Richard's 2011-09-05 change to gas/dwarf2dbg.c.
I reckon the test itself is somewhat suspect, since .loc specifies
line number info for instructions, and the test has no instructions
(unless you count .space as an instruction).  So, let's fix the test.

I'm not hugely concerned, but the old test does illustrate some
problems with queuing line info:  We don't emit queued line info if
.loc is not followed by an insn or label (no line info at all for the
old test), and perhaps the queue should be flushed on pseudos like
.space that bump pc?  gcc asm can do all sorts of weird tricks.  eg.

int foo (void)
{
  __asm__ (".p2align 8");
  return 0;
}

results in

        .loc 1 3 0
#APP
# 3 "/src/tmp/asmloc.c" 1
        .p2align 8
# 0 "" 2
        .loc 1 4 0
#NO_APP
        movl    $0, %eax

so with queuing, the ".p2align" loses its line number info to the
"movl".  Thoughts?

* gas/lns/lns-big-delta.s: Add nops.
* gas/lns/lns-&lt;/pre&gt;</description>
    <dc:creator>Alan Modra</dc:creator>
    <dc:date>2012-05-24T15:35:42</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gnu.binutils/57712">
    <title>pr14158, hole in powerpc64 .eh_frame</title>
    <link>http://comments.gmane.org/gmane.comp.gnu.binutils/57712</link>
    <description>&lt;pre&gt;PowerPC64 linker generated .eh_frame for PLT call stubs uses
DW_EH_PE_pcrel | DW_EH_PE_sdata4 encoding for addresses, and thus
aligns .eh_frame to 4 bytes.  Current gcc uses the same encoding, but
probably because gcc hasn't changed its .eh_frame alignment from the
days it generated 8-byte addresses, aligns to 8 bytes.  This means ld
will insert padding between the linker generated .eh_frame and user
.eh_frame sections.  The padding is seen as a terminator, which breaks
exception handling for anyone not reading the FDEs via .eh_frame_hdr.
The common case of course is to call ld with --eh-frame-hdr, which is
why I hadn't seen this problem until now.

PR ld/14158
* elf64-ppc.c (ppc64_elf_size_stubs): Round up glink_eh_frame
size to output section alignment.
(ppc64_elf_build_stubs): Likewise, and extend last FDE to cover.

Index: bfd/elf64-ppc.c
===================================================================
RCS file: /cvs/src/src/bfd/elf64-ppc.c,v
retrieving revision 1.383
diff -u -p -r1.383 elf64-ppc.&lt;/pre&gt;</description>
    <dc:creator>Alan Modra</dc:creator>
    <dc:date>2012-05-24T06:20:12</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gnu.binutils/57702">
    <title>[gold patch] Fix gold to match .data.rel.ro sections more carefully</title>
    <link>http://comments.gmane.org/gmane.comp.gnu.binutils/57702</link>
    <description>&lt;pre&gt;This patch fixes gold, which has the same problem placing
.data.rel.rome (for example) in the .data.rel.ro section.

Tested on x86_64.

OK to commit?

-cary


2012-05-23  Cary Coutant  &amp;lt;ccoutant&amp;lt; at &amp;gt;google.com&amp;gt;

gold/
* layout.cc (Layout::section_name_mapping): Match .data.rel.ro.*
more carefully.


commit 4055988862278017c0564c81e8cee7fd001e6507
Author: Cary Coutant &amp;lt;ccoutant&amp;lt; at &amp;gt;google.com&amp;gt;
Date:   Wed May 23 11:44:38 2012 -0700

    Fix handling of .data.rel.ro* vs. .data.rel.ro.* sections.

diff --git a/gold/layout.cc b/gold/layout.cc
index 0ac0fbf..e9aeef5 100644
--- a/gold/layout.cc
+++ b/gold/layout.cc
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -4573,8 +4573,8 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; const Layout::Section_name_mapping
Layout::section_name_mapping[] =
 {
   MAPPING_INIT(".text.", ".text"),
   MAPPING_INIT(".rodata.", ".rodata"),
-  MAPPING_INIT(".data.rel.ro.local", ".data.rel.ro.local"),
-  MAPPING_INIT(".data.rel.ro", ".data.rel.ro"),
+  MAPPING_INIT(".data.rel.ro.local.", ".data.rel.ro.local"),
+  MAPPING_INIT(".data.rel.ro.", ".data.rel.ro"),
   MAPPING_INIT(".dat&lt;/pre&gt;</description>
    <dc:creator>Cary Coutant</dc:creator>
    <dc:date>2012-05-23T19:05:44</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gnu.binutils/57701">
    <title>[patch] Fix ld to match .data.rel.ro sections more carefully</title>
    <link>http://comments.gmane.org/gmane.comp.gnu.binutils/57701</link>
    <description>&lt;pre&gt;Both GNU ld and gold share a problem where a variable whose name
begins with "ro" might accidentally end up in a RELRO segment. Compile
the following test program with -fpic -fdata-sections:

#include &amp;lt;stdio.h&amp;gt;

char p[] = "Paris";
char r[] = "Rome";
char l[] = "London";

const char * const paris = p;
const char * rome = r;
const char * london = l;

int main()
{
  printf("%s\n", paris);
  printf("%s\n", london);
  london = "England";
  printf("%s\n", london);
  printf("%s\n", rome);
  rome = "Italy";
  printf("%s\n", rome);
  return 0;
}

The variable "rome" is placed in a data section named
".data.rel.rome", and that matches the pattern that ld uses to place
input sections into .data.rel.ro, which then gets placed in the RELRO
segment, and the program segfaults when trying to assign to "rome".

The attached patch fixes this by matching ".data.rel.ro" and
".data.rel.ro.*" separately (a pattern used for most other similar
cases, but not for the relro sections), and likewise for the
corresponding relocation se&lt;/pre&gt;</description>
    <dc:creator>Cary Coutant</dc:creator>
    <dc:date>2012-05-23T18:58:55</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gnu.binutils/57698">
    <title>[RFA] leb128.h: Umm, how about int64_t?</title>
    <link>http://comments.gmane.org/gmane.comp.gnu.binutils/57698</link>
    <description>&lt;pre&gt;It turns out gdb can't use long long but it can use {,u}int64_t.

[Insert lament that we're debating whether to switch to C++ and yet
we can't even use C99. :-(]

I opted for renaming the functions instead of adding new ones
since there'd be no current users.  I left adding the long long
versions back for when there's an actual need for them.

Ok to check in?

2012-05-23  Doug Evans  &amp;lt;dje&amp;lt; at &amp;gt;google.com&amp;gt;

* leb128.h: #include stdint.h, inttypes.h.
(read_uleb128_to_uint64): Renamed from read_uleb128_to_ull.
Change to take a uint64_t * argument instead of unsigned long long.
(read_sleb128_to_uint64): Renamed from read_sleb128_to_ll.
Change to take an int64_t * argument instead of long long.

Index: leb128.h
===================================================================
RCS file: /cvs/src/src/include/leb128.h,v
retrieving revision 1.1
diff -u -p -r1.1 leb128.h
--- leb128.h22 May 2012 18:05:30 -00001.1
+++ leb128.h23 May 2012 16:27:53 -0000
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -19,7 +19,12 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; Boston, MA 02110-1301, USA.  */
 
 /* The fu&lt;/pre&gt;</description>
    <dc:creator>Doug Evans</dc:creator>
    <dc:date>2012-05-23T16:41:22</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gnu.binutils/57697">
    <title>[Patch,AVR] Support instrucions XCH, LAT, LAC, LAS</title>
    <link>http://comments.gmane.org/gmane.comp.gnu.binutils/57697</link>
    <description>&lt;pre&gt;This patch adds support for the XMEGA atomic memory instructions

o exchange
o load-and-set
o load-and-clear
o load-and-toggle


Johann


include/
* opcode/avr.h (AVR_ISA_XCH): New define.
(AVR_ISA_XMEGA): Use it.
(XCH, LAS, LAT, LAC): New XMEGA opcodes.
&lt;/pre&gt;</description>
    <dc:creator>Georg-Johann Lay</dc:creator>
    <dc:date>2012-05-23T16:15:50</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gnu.binutils/57693">
    <title>RFC: Displaying multibyte symbol names in readelf</title>
    <link>http://comments.gmane.org/gmane.comp.gnu.binutils/57693</link>
    <description>&lt;pre&gt;Hi Guys,

  I am planning to apply the patch below to enhance readelf so that it
  can display symbol names that contain multibyte characters.  Currently
  such characters are displayed as a sequence of hex-bytes.  With the
  patch applied the actual multibyte characters will be displayed
  provided that the user's terminal and environment settings support
  them.

  Does anyone have any objections or questions concerning adding such a
  feature ?

Cheers
  Nick
    
binutils/ChangeLog
2012-05-23  Nick Clifton  &amp;lt;nickc&amp;lt; at &amp;gt;redhat.com&amp;gt;

* readelf.c (print_symbol): Display multibyte characters.
  
Index: binutils/readelf.c
===================================================================
RCS file: /cvs/src/src/binutils/readelf.c,v
retrieving revision 1.573
diff -u -3 -p -r1.573 readelf.c
--- binutils/readelf.c15 May 2012 12:55:49 -00001.573
+++ binutils/readelf.c23 May 2012 07:33:30 -0000
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -48,6 +48,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt;
 #ifdef HAVE_ZLIB_H
 #include &amp;lt;zlib.h&amp;gt;
 #endif
+#include &amp;lt;wchar.h&amp;gt;
 
 #if __GNUC__ &amp;gt;= 2
 /* Define BFD64&lt;/pre&gt;</description>
    <dc:creator>Nick Clifton</dc:creator>
    <dc:date>2012-05-23T11:14:09</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gnu.binutils/57687">
    <title>PATCH: Don't skip ld-elf/eh[1-4].d for x32</title>
    <link>http://comments.gmane.org/gmane.comp.gnu.binutils/57687</link>
    <description>&lt;pre&gt;Hi,

I checked in this patch not to skip ld-elf/eh[1-4].d for x32.


H.J.
---
Index: ChangeLog
===================================================================
RCS file: /cvs/src/src/ld/testsuite/ChangeLog,v
retrieving revision 1.1549
diff -u -p -r1.1549 ChangeLog
--- ChangeLog22 May 2012 21:42:50 -00001.1549
+++ ChangeLog22 May 2012 21:51:22 -0000
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -1,5 +1,12 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt;
 2012-05-22  H.J. Lu  &amp;lt;hongjiu.lu&amp;lt; at &amp;gt;intel.com&amp;gt;
 
+* ld-elf/eh1.d: Don't skip x86_64-*-linux-gnux32.
+* ld-elf/eh2.d: Likewise.
+* ld-elf/eh3.d: Likewise.
+* ld-elf/eh4.d: Likewise.
+
+2012-05-22  H.J. Lu  &amp;lt;hongjiu.lu&amp;lt; at &amp;gt;intel.com&amp;gt;
+
 * ld-x86-64/ilp32-11.s Add ".space 0x1000" before func.
 (func): Make it global and hidden.
 * ld-x86-64/ilp32-11.d: Updated.
Index: ld-elf/eh1.d
===================================================================
RCS file: /cvs/src/src/ld/testsuite/ld-elf/eh1.d,v
retrieving revision 1.8
diff -u -p -r1.8 eh1.d
--- ld-elf/eh1.d4 May 2012 20:01:02 -00001.8
+++ ld-elf/eh1.d22 May 2012 21:51:22 -0000
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -3,7 +3&lt;/pre&gt;</description>
    <dc:creator>H.J. Lu</dc:creator>
    <dc:date>2012-05-22T21:53:06</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gnu.binutils/57685">
    <title>[gold patch] Fix problem with --export-dynamic-symbol and versioned symbols</title>
    <link>http://comments.gmane.org/gmane.comp.gnu.binutils/57685</link>
    <description>&lt;pre&gt;The --dynamic-list and --export-dynamic-symbol options can trigger an
internal error in Symbol_table::sized_finalize_symbol() if a named
symbol is referenced with a version from a dynamic object. In that
case, we try to force a dynamic symbol table entry for the versioned
symbol in the dynamic object. This patch fixes the problem by forcing
the dynamic symbol table entry only after checking that the symbol is
defined in a non-shared object.

Tested on x86_64. OK to commit?

-cary


2012-05-22  Cary Coutant  &amp;lt;ccoutant&amp;lt; at &amp;gt;google.com&amp;gt;

* symtab.cc (Symbol::should_add_dynsym_entry): Check for relocatable
object before exporting symbol.


commit 932930f6aaa2e75093e97d57eb90128d1da635ab
Author: Cary Coutant &amp;lt;ccoutant&amp;lt; at &amp;gt;google.com&amp;gt;
Date:   Tue May 22 13:58:32 2012 -0700

    Don't export symbols from shared objects.

diff --git a/gold/symtab.cc b/gold/symtab.cc
index a820b0a..1bb9867 100644
--- a/gold/symtab.cc
+++ b/gold/symtab.cc
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -365,8 +365,10 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; Symbol::should_add_dynsym_entry(Symbol_table* symtab) const

   //&lt;/pre&gt;</description>
    <dc:creator>Cary Coutant</dc:creator>
    <dc:date>2012-05-22T21:12:52</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gnu.binutils/57684">
    <title>[PATCH] fix some ld testsuite regressions for arm-nacl targets</title>
    <link>http://comments.gmane.org/gmane.comp.gnu.binutils/57684</link>
    <description>&lt;pre&gt;I noticed two failures in the ld testsuite in a --target=arm-nacl build
that I had not gotten before.  I think in both cases I just failed to
notice because I had not always removed ld/tmpdir between test runs,
and these are tests that rely on files left there by other tests run
earlier in the sequence.

Ok for trunk?


Thanks,
Roland


ld/testsuite/
2012-05-22  Roland McGrath  &amp;lt;mcgrathr&amp;lt; at &amp;gt;google.com&amp;gt;

* ld-arm/arm-elf.exp (armelftests_common): Add a test that gets
arm-lib.so built so armeabitests_common can use it.
(unresolved-1-dyn): Exclude this test for [istarget "arm*-*-nacl*"].

diff --git a/ld/testsuite/ld-arm/arm-elf.exp b/ld/testsuite/ld-arm/arm-elf.exp
index b6eb3d3..3f6f1a0 100644
--- a/ld/testsuite/ld-arm/arm-elf.exp
+++ b/ld/testsuite/ld-arm/arm-elf.exp
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -268,6 +268,9 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; set armelftests_common {
     {"abs call" "-T arm.ld" "" {abs-call-1.s}
      {{objdump -d abs-call-1.d}}
      "abs-call-1"}
+    {"Simple non-PIC shared library (no PLT check)" "-shared" "" {arm-lib.s}
+     {{objdump -Rw a&lt;/pre&gt;</description>
    <dc:creator>Roland McGrath</dc:creator>
    <dc:date>2012-05-22T20:04:09</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gnu.binutils/57679">
    <title>[PATCH] loosen eh4.d test regexps so x86_64-*-nacl* passes too</title>
    <link>http://comments.gmane.org/gmane.comp.gnu.binutils/57679</link>
    <description>&lt;pre&gt;This is the very same issue as the last change I posted, solved similarly.

In future, please contact me before adding any XFAILs or exclusions for
any *-*-nacl* targets.  We don't want to have any less testing for these
targets, and usually simple tweaks like these are all it takes.

Ok for trunk?


Thanks,
Roland


ld/testsuite/
* ld-elf/eh4.d: Revert last change.
Loosen CFI-matching regexps so they match x86_64-*-nacl* variant too.

diff --git a/ld/testsuite/ld-elf/eh4.d b/ld/testsuite/ld-elf/eh4.d
index a708efd..29f418f 100644
--- a/ld/testsuite/ld-elf/eh4.d
+++ b/ld/testsuite/ld-elf/eh4.d
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -3,7 +3,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt;
 #as: --64
 #ld: -melf_x86_64 -shared -Ttext 0x400
 #readelf: -wf
-#notarget: x86_64-*-linux-gnux32 x86_64-*-nacl*
+#notarget: x86_64-*-linux-gnux32
 #target: x86_64-*-*
 
 Contents of the .eh_frame section:
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -29,17 +29,14 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; Contents of the .eh_frame section:
   DW_CFA_set_loc: 00000417
   DW_CFA_def_cfa_offset: 80
 
-00000048 00000024 0000004c FDE cie=00000000 pc=00000240..00000260
+00000048 00000&lt;/pre&gt;</description>
    <dc:creator>Roland McGrath</dc:creator>
    <dc:date>2012-05-22T18:25:27</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gnu.binutils/57677">
    <title>[PATCH] loosen PR ld/12570 test regexps so x86_64-*-nacl* passes too</title>
    <link>http://comments.gmane.org/gmane.comp.gnu.binutils/57677</link>
    <description>&lt;pre&gt;The issue being tested for applies to x86_64-*-nacl* targets just as well
but the precise contents of their PLT CFI differs.  This loosens the
regexps matching the CFI so that both variants are accepted.

Ok for trunk?


Thanks,
Roland


ld/testsuite/
2012-05-22  Roland McGrath  &amp;lt;mcgrathr&amp;lt; at &amp;gt;google.com&amp;gt;

* ld-x86-64/pr12570a.d (name): Distinguish it from pr12570b.d case.
Loosen CFI-matching regexp so it matches x86_64-*-nacl* variant too.
* ld-x86-64/pr12570b.d: Likewise.

diff --git a/ld/testsuite/ld-x86-64/pr12570a.d b/ld/testsuite/ld-x86-64/pr12570a.d
index 6105a74..1d79411 100644
--- a/ld/testsuite/ld-x86-64/pr12570a.d
+++ b/ld/testsuite/ld-x86-64/pr12570a.d
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -1,8 +1,8 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt;
-#name: PR ld/12570
+#name: PR ld/12570 (PLT)
 #as: --64
 #ld: -melf_x86_64 -shared
 #readelf: -wf --wide
 
 #...
-  DW_CFA_def_cfa_expression \(DW_OP_breg7 \(rsp\): 8; DW_OP_breg16 \(rip\): 0; DW_OP_lit15; DW_OP_and; DW_OP_lit11; DW_OP_ge; DW_OP_lit3; DW_OP_shl; DW_OP_plus\)
+  DW_CFA_def_cfa_expression \(DW_OP_breg7 \(rsp\): 8; DW_O&lt;/pre&gt;</description>
    <dc:creator>Roland McGrath</dc:creator>
    <dc:date>2012-05-22T18:07:08</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gnu.binutils/57676">
    <title>PATCH: Skip/xfail x86_64-*-nacl* for eh4 and pr12570a tests</title>
    <link>http://comments.gmane.org/gmane.comp.gnu.binutils/57676</link>
    <description>&lt;pre&gt;Hi,

X86-64 NACL has different PLT entries.  I checked in this patch to
skip/xfail x86_64-*-nacl* for eh4 and pr12570a tests.

H.J.
---
diff --git a/ld/testsuite/ChangeLog b/ld/testsuite/ChangeLog
index c3ad1ab..d159063 100644
--- a/ld/testsuite/ChangeLog
+++ b/ld/testsuite/ChangeLog
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -1,5 +1,11 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt;
 2012-05-22  H.J. Lu  &amp;lt;hongjiu.lu&amp;lt; at &amp;gt;intel.com&amp;gt;
 
+* ld-elf/eh4.d: Skip x86_64-*-nacl*.
+
+* ld-x86-64/x86-64.exp: Xfail pr12570a for x86_64-*-nacl*.
+
+2012-05-22  H.J. Lu  &amp;lt;hongjiu.lu&amp;lt; at &amp;gt;intel.com&amp;gt;
+
 PR ld/13909
 * ld-i386/i386.exp: Revert the last change.
 * ld-x86-64/x86-64.exp: Likewise.
diff --git a/ld/testsuite/ld-elf/eh4.d b/ld/testsuite/ld-elf/eh4.d
index 34ce70e..a708efd 100644
--- a/ld/testsuite/ld-elf/eh4.d
+++ b/ld/testsuite/ld-elf/eh4.d
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -3,7 +3,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt;
 #as: --64
 #ld: -melf_x86_64 -shared -Ttext 0x400
 #readelf: -wf
-#notarget: x86_64-*-linux-gnux32
+#notarget: x86_64-*-linux-gnux32 x86_64-*-nacl*
 #target: x86_64-*-*
 
 Contents of the .eh_frame section:
diff --git a/ld/testsuite/ld-x86-64/x86-64&lt;/pre&gt;</description>
    <dc:creator>H.J. Lu</dc:creator>
    <dc:date>2012-05-22T16:58:58</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gnu.binutils/57670">
    <title>PATCH: PR ld/13909: PR ld/12570 causes eh_frame_hdr section to be sometimes too large</title>
    <link>http://comments.gmane.org/gmane.comp.gnu.binutils/57670</link>
    <description>&lt;pre&gt;Hi,

Now we support mulltiple .eh_frame sections, we can create PLT eh_frame
section if there is an input .eh_frame section.  I am checking in this
patch for i386 and x86-64.  I will leave other targets to their
maintainers.

Thanks.

H.J.
---
diff --git a/bfd/ChangeLog.pr13909 b/bfd/ChangeLog.pr13909
new file mode 100644
index 0000000..dce7c71
--- /dev/null
+++ b/bfd/ChangeLog.pr13909
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -0,0 +1,6 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt;
+2012-05-14  H.J. Lu  &amp;lt;hongjiu.lu&amp;lt; at &amp;gt;intel.com&amp;gt;
+
+PR ld/13909
+* elf32-i386.c (elf_i386_create_dynamic_sections): Create PLT
+eh_frame section if there is an input .eh_frame section.
+* elf64-x86-64.c (elf_x86_64_create_dynamic_sections): Likewise.
diff --git a/bfd/elf32-i386.c b/bfd/elf32-i386.c
index 31b3c57..49387e7 100644
--- a/bfd/elf32-i386.c
+++ b/bfd/elf32-i386.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -1016,7 +1016,8 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; elf_i386_create_dynamic_sections (bfd *dynobj, struct bfd_link_info *info)
 
   if (!info-&amp;gt;no_ld_generated_unwind_info
       &amp;amp;&amp;amp; htab-&amp;gt;plt_eh_frame == NULL
-      &amp;amp;&amp;amp; htab-&amp;gt;elf.splt != NULL)
+      &amp;amp;&amp;amp; htab-&amp;gt;elf.splt != NU&lt;/pre&gt;</description>
    <dc:creator>H.J. Lu</dc:creator>
    <dc:date>2012-05-22T14:11:09</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gnu.binutils/57649">
    <title>[PATCH] Add support for m68k-linux core file notes</title>
    <link>http://comments.gmane.org/gmane.comp.gnu.binutils/57649</link>
    <description>&lt;pre&gt;Tested on m68k-linux and powerpc-linux.

Andreas.

* elf32-m68k.c (elf_m68k_grok_prstatus): New function.
(elf_m68k_grok_psinfo): New function.
(elf_backend_grok_prstatus): Define.
(elf_backend_grok_psinfo): Define.
---
 bfd/elf32-m68k.c |   65 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 65 insertions(+)

diff --git a/bfd/elf32-m68k.c b/bfd/elf32-m68k.c
index b66f95a..6c12fa7 100644
--- a/bfd/elf32-m68k.c
+++ b/bfd/elf32-m68k.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -4821,6 +4821,69 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; elf_m68k_plt_sym_val (bfd_vma i, const asection *plt,
   return plt-&amp;gt;vma + (i + 1) * elf_m68k_get_plt_info (plt-&amp;gt;owner)-&amp;gt;size;
 }
 
+/* Support for core dump NOTE sections.  */
+
+static bfd_boolean
+elf_m68k_grok_prstatus (bfd *abfd, Elf_Internal_Note *note)
+{
+  int offset;
+  size_t size;
+
+  switch (note-&amp;gt;descsz)
+    {
+    default:
+      return FALSE;
+
+    case 154:/* Linux/m68k */
+      /* pr_cursig */
+      elf_tdata (abfd)-&amp;gt;core_signal = bfd_get_16 (abfd, note-&amp;gt;descdata + 12);
+
+      /* pr_pid */
+      elf_tda&lt;/pre&gt;</description>
    <dc:creator>Andreas Schwab</dc:creator>
    <dc:date>2012-05-20T18:02:39</dc:date>
  </item>
  <textinput rdf: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>

