[Bug ld/10433] Latest ld fails to link ldconfig properly

2009-08-03 Thread cvs-commit at gcc dot gnu dot org 

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2009-08-03 
15:51 ---
Subject: Bug 10433

CVSROOT:/cvs/src
Module name:src
Changes by: h...@sourceware.org 2009-08-03 15:50:51

Modified files:
bfd: ChangeLog elf-ifunc.c 

Log message:
2009-08-03  H.J. Lu  hongjiu...@intel.com

PR ld/10433
* elf-ifunc.c (_bfd_elf_allocate_ifunc_dyn_relocs): Set got
to htab-init_got_offset and plt to htab-init_plt_offset
when discarding space for dynamic relocations.

Patches:
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/bfd/ChangeLog.diff?cvsroot=srcr1=1.4715r2=1.4716
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/bfd/elf-ifunc.c.diff?cvsroot=srcr1=1.2r2=1.3



-- 


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

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/10433] Latest ld fails to link ldconfig properly

2009-08-03 Thread hjl dot tools at gmail dot com 

--- Additional Comments From hjl dot tools at gmail dot com  2009-08-03 
15:53 ---
Fixed.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/10433] Latest ld fails to link ldconfig properly

2009-07-30 Thread hjl dot tools at gmail dot com 

--- Additional Comments From hjl dot tools at gmail dot com  2009-07-30 
16:50 ---
If all relocations against an IFUNC symbol are in the same file
where it is defined, the ref_regular field may not be set. I
changed the x86 linker to set it properly for IFUNC symbols. We
need to do it. Otherwise we will run into this bug. If not all
backends need it, we can change elflink.c from

 if ((h-type == STT_GNU_IFUNC
h-def_regular
!finfo-info-relocatable)

to

 if ((h-type == STT_GNU_IFUNC
   !finfo-info-relocatable
   bed-need_finish_dynamic_ifunc_symbol (h))

It will be default to h-def_regular. I can provide a patch if it is
OK.


-- 
   What|Removed |Added

 Status|SUSPENDED   |NEW


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

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/10433] Latest ld fails to link ldconfig properly

2009-07-30 Thread amodra at bigpond dot net dot au 

--- Additional Comments From amodra at bigpond dot net dot au  2009-07-31 
01:03 ---
bed-need_finish_dynamic_ifunc_symbol is unacceptable in my opinion.

Comment #3 says the only difference between good and bad binaries was a
.rela.plt relocation.  That would seem to indicate that the relocation is being
written once with the good symbol, then overwritten with the bad one, when,
as you claim, elf_backend_finish_dynamic_symbol is being called unexpectedly. 
But that means you must have other bugs, since the bad symbol must have
plt.offset != -1, which indicates it has a plt entry at the same location as the
good symbol!

I think you are just papering over real bugs by wanting changes to the set of
symbols for which elf_backend_finish_dynamic_symbol is called.

-- 


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

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/10433] Latest ld fails to link ldconfig properly

2009-07-30 Thread hjl dot tools at gmail dot com 

--- Additional Comments From hjl dot tools at gmail dot com  2009-07-31 
02:50 ---
(In reply to comment #20)
 
 Comment #3 says the only difference between good and bad binaries was a
 .rela.plt relocation.  That would seem to indicate that the relocation is 
 being
 written once with the good symbol, then overwritten with the bad one, 
 when,
 as you claim, elf_backend_finish_dynamic_symbol is being called unexpectedly. 
 But that means you must have other bugs, since the bad symbol must have
 plt.offset != -1, which indicates it has a plt entry at the same location as 
 the
 good symbol!
 

This patch:

Index: elf-ifunc.c
===
--- elf-ifunc.c (revision 6507)
+++ elf-ifunc.c (working copy)
@@ -193,6 +193,7 @@ _bfd_elf_allocate_ifunc_dyn_relocs (stru
  || h-got.refcount  0)
abort ();
   h-got.offset = (bfd_vma) -1;
+  h-plt.offset = (bfd_vma) -1;
   *head = NULL;
   return TRUE;
 }

seems to work. I will test it with glibc build.

-- 


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

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/10433] Latest ld fails to link ldconfig properly

2009-07-29 Thread amodra at bigpond dot net dot au 

--- Additional Comments From amodra at bigpond dot net dot au  2009-07-30 
01:26 ---
 Your change duplicates the logic in elf_link_output_extsym so that
 you can fix this bug. You have to do this for all backends which
 support IFUNC symbols.

Rubbish.  See for example the powerpc backend.

 That begs the question why it shouldn't be
 done in elf_link_output_extsym. Can someone give me one good reason
 for this madness?  Thanks.

I've already stated why ref_regular should not be tested in generic code.  Why
do you keep ignoring me?  You can fix your backend either with the boilerplate
style patch Nick presented or more elegantly.  More elegantly is preferable.

In fact, completely reimplementing your ifunc support for x86 is preferable. 
The only madness involved here was trusting your implementation enough to
allow it to be committed.  It looks like you have just kept adding code until it
worked for the limited set of testcases you have assembled and linked.  For an
example of your muddy thinking, I need look no further than check_relocs. 
There, you start doing special things for ifunc symbols when def_regular.  But
check_relocs is called as each object file is added.  So your code can't work if
a regular object file references an undefined symbol which a later regular
object file defines as STT_GNU_IFUNC.  When check_relocs is called for the first
object file it just sees a normal undefined symbol.  No special treatment for
ifunc.  When check_relocs is called for the later object, there may be no
reference in it to the ifunc definition.  Again no special treatment for ifunc.

-- 


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

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/10433] Latest ld fails to link ldconfig properly

2009-07-29 Thread hjl dot tools at gmail dot com 

--- Additional Comments From hjl dot tools at gmail dot com  2009-07-30 
04:57 ---
(In reply to comment #17)
  Your change duplicates the logic in elf_link_output_extsym so that
  you can fix this bug. You have to do this for all backends which
  support IFUNC symbols.
 
 Rubbish.  See for example the powerpc backend.
 
  That begs the question why it shouldn't be
  done in elf_link_output_extsym. Can someone give me one good reason
  for this madness?  Thanks.
 
 I've already stated why ref_regular should not be tested in generic code.  Why
 do you keep ignoring me?  You can fix your backend either with the 
 boilerplate
 style patch Nick presented or more elegantly.  More elegantly is preferable.
 
 In fact, completely reimplementing your ifunc support for x86 is preferable. 
 The only madness involved here was trusting your implementation enough to
 allow it to be committed.  It looks like you have just kept adding code until 
 it
 worked for the limited set of testcases you have assembled and linked.  For 
 an
 example of your muddy thinking, I need look no further than check_relocs. 
 There, you start doing special things for ifunc symbols when def_regular.  But
 check_relocs is called as each object file is added.  So your code can't work 
 if
 a regular object file references an undefined symbol which a later regular
 object file defines as STT_GNU_IFUNC.  When check_relocs is called for the 
 first
 object file it just sees a normal undefined symbol.  No special treatment for
 ifunc.  When check_relocs is called for the later object, there may be no
 reference in it to the ifunc definition.  Again no special treatment for 
 ifunc.

If you can find a testcase to show IFUNC problems on x86, I will
fix them. In the meantime, let's wait until you finish IFUNC for
Power and pass all IFUNC tests in glibc. I will take a look at what
you did and update x86 backends if necessary.  Thanks.


-- 
   What|Removed |Added

 Status|WAITING |SUSPENDED


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

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/10433] Latest ld fails to link ldconfig properly

2009-07-27 Thread nickc at redhat dot com 

--- Additional Comments From nickc at redhat dot com  2009-07-27 17:13 
---
Created an attachment (id=4090)
 -- (http://sourceware.org/bugzilla/attachment.cgi?id=4090action=view)
Revised version of the patch


-- 
   What|Removed |Added

Attachment #4078 is|0   |1
   obsolete||


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

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/10433] Latest ld fails to link ldconfig properly

2009-07-27 Thread nickc at redhat dot com 

--- Additional Comments From nickc at redhat dot com  2009-07-27 17:14 
---
Hi H.J.

 I am afraid it is wrong. You have to duplicate the whole
 logic in elf_link_output_extsym:

Of course.  My bad.  So do you agree that the revised version of this patch will
work for the x86 and x86_64 backends ?

Cheers
  Nick




-- 
   What|Removed |Added

 Status|NEW |WAITING


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

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/10433] Latest ld fails to link ldconfig properly

2009-07-27 Thread hjl dot tools at gmail dot com 

--- Additional Comments From hjl dot tools at gmail dot com  2009-07-27 
17:26 ---
(In reply to comment #15)
 Hi H.J.
 
  I am afraid it is wrong. You have to duplicate the whole
  logic in elf_link_output_extsym:
 
 Of course.  My bad.  So do you agree that the revised version of this patch 
 will
 work for the x86 and x86_64 backends ?
 

Your change duplicates the logic in elf_link_output_extsym so that
you can fix this bug. You have to do this for all backends which
support IFUNC symbols. That begs the question why it shouldn't be
done in elf_link_output_extsym. Can someone give me one good reason
for this madness?  Thanks.



-- 


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

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/10433] Latest ld fails to link ldconfig properly

2009-07-23 Thread nickc at redhat dot com 

--- Additional Comments From nickc at redhat dot com  2009-07-23 08:40 
---
Created an attachment (id=4078)
 -- (http://sourceware.org/bugzilla/attachment.cgi?id=4078action=view)
Do not generate PLT entries for IFUNC symbols when they are defined, only when
they are referenced.


-- 


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

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/10433] Latest ld fails to link ldconfig properly

2009-07-23 Thread hjl dot tools at gmail dot com 

--- Additional Comments From hjl dot tools at gmail dot com  2009-07-23 
13:24 ---
(In reply to comment #10)
 Created an attachment (id=4078)
 -- (http://sourceware.org/bugzilla/attachment.cgi?id=4078action=view)
 Do not generate PLT entries for IFUNC symbols when they are defined, only when
 they are referenced.
 

My original change is for IFUNC symbol in static executables.
If a backend supports IFUNC symbol, it has to set the ref_regular
field properly for IFUNC symbol. This patch is unnecessary and
doesn't help any targets. Feel free to check it in if it works
with glibc on x86. I will simply revert it and apply my patch
for Linux binutils instead.

-- 


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

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/10433] Latest ld fails to link ldconfig properly

2009-07-23 Thread hjl dot tools at gmail dot com 

--- Additional Comments From hjl dot tools at gmail dot com  2009-07-23 
13:29 ---
(In reply to comment #11)
 Hi H.J.
 
   Will the uploaded patch work ?
 

I am afraid it is wrong. You have to duplicate the whole
logic in elf_link_output_extsym:

  if ((h-type == STT_GNU_IFUNC
h-def_regular
!finfo-info-relocatable)
  || ((h-dynindx != -1
   || h-forced_local)
   ((finfo-info-shared
(ELF_ST_VISIBILITY (h-other) == STV_DEFAULT
   || h-root.type != bfd_link_hash_undefweak))
  || !h-forced_local)
   elf_hash_table (finfo-info)-dynamic_sections_created))
{

Otherwise, you will miss the || part. Like I said, the backend is
the wrong place to fix this bug.


-- 
   What|Removed |Added

 Status|WAITING |NEW


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

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/10433] Latest ld fails to link ldconfig properly

2009-07-22 Thread drepper at redhat dot com 

--- Additional Comments From drepper at redhat dot com  2009-07-22 20:10 
---
This suggests it's a problem in the IFUNC handling as stpcpy and stpncpy are
IFUNC symbols.

-- 


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

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/10433] Latest ld fails to link ldconfig properly

2009-07-22 Thread jakub at redhat dot com 

--- Additional Comments From jakub at redhat dot com  2009-07-22 20:11 
---
Ah, attachment too large.
Use http://sunsite.mff.cuni.cz/private/ldconfig.tar.bz2
instead.

-- 


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

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/10433] Latest ld fails to link ldconfig properly

2009-07-22 Thread hjl dot tools at gmail dot com 


-- 
   What|Removed |Added

 AssignedTo|unassigned at sources dot   |hjl dot tools at gmail dot
   |redhat dot com  |com
 Status|NEW |ASSIGNED


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

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/10433] Latest ld fails to link ldconfig properly

2009-07-22 Thread jakub at redhat dot com 

--- Additional Comments From jakub at redhat dot com  2009-07-22 20:52 
---
When linked with 2.19.51.0.11 (which works), .rela.plt contains:
Relocation section '.rela.plt' at offset 0x1a0 contains 8 entries:
Offset Info Type   Symbol's Value 
Symbol's Name + Addend
006c65d0  0025 R_X86_64_IRELATIVE   
  00421a50
006c65d8  0025 R_X86_64_IRELATIVE   
  0041f720
006c65e0  0025 R_X86_64_IRELATIVE   
  00423a30
006c65e8  0025 R_X86_64_IRELATIVE   
  00423a30
006c65f0  0025 R_X86_64_IRELATIVE   
  00423ed0
006c65f8  0025 R_X86_64_IRELATIVE   
  00479060
006c6600  0025 R_X86_64_IRELATIVE   
  0041e760
006c6608  0025 R_X86_64_IRELATIVE   
  0047a030

where
  2532: 0047a03068 IFUNC   WEAK   DEFAULT6 stpncpy
  1394: 00421a5068 IFUNC   WEAK   DEFAULT6 stpcpy

But when linked with trunk, this is:
006c65d0  0025 R_X86_64_IRELATIVE   
  0047a030
006c65d8  0025 R_X86_64_IRELATIVE   
  0041f720
006c65e0  0025 R_X86_64_IRELATIVE   
  00423a30
006c65e8  0025 R_X86_64_IRELATIVE   
  00423a30
006c65f0  0025 R_X86_64_IRELATIVE   
  00423ed0
006c65f8  0025 R_X86_64_IRELATIVE   
  00479060
006c6600  0025 R_X86_64_IRELATIVE   
  0041e760
006c6608  0025 R_X86_64_IRELATIVE   
  0047a030

and the symbols are the same.  And indeed, the only changes between the two
binaries are 3 bytes in .rela.plt section:
 Relocation section '.rela.plt' at offset 0x1a0 contains 8 entries:
 Offset Info Type   Symbol's Value 
Symbol's Name + Addend
-006c65d0  0025 unrecognized: 25
  0047a030
+006c65d0  0025 unrecognized: 25
  00421a50
and content of .note.gnu.build-id section.

-- 


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

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/10433] Latest ld fails to link ldconfig properly

2009-07-22 Thread hjl dot tools at gmail dot com 

--- Additional Comments From hjl dot tools at gmail dot com  2009-07-22 
21:17 ---
It is caused by

http://sourceware.org/ml/binutils/2009-07/msg00092.html

-- 
   What|Removed |Added

 CC||amodra at bigpond dot net
   ||dot au


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

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/10433] Latest ld fails to link ldconfig properly

2009-07-22 Thread hjl dot tools at gmail dot com 

--- Additional Comments From hjl dot tools at gmail dot com  2009-07-22 
21:26 ---
This patch:

Index: elflink.c
===
--- elflink.c   (revision 6448)
+++ elflink.c   (working copy)
@@ -8662,7 +8662,7 @@ elf_link_output_extsym (struct elf_link_
  forced local syms when non-shared is due to a historical quirk.
  STT_GNU_IFUNC symbol must go through PLT.  */
   if ((h-type == STT_GNU_IFUNC
-h-def_regular
+h-ref_regular
 !finfo-info-relocatable)
   || ((h-dynindx != -1
   || h-forced_local)

fixes it. I will check it with some comments.

-- 


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

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/10433] Latest ld fails to link ldconfig properly

2009-07-22 Thread cvs-commit at gcc dot gnu dot org 

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2009-07-22 
21:30 ---
Subject: Bug 10433

CVSROOT:/cvs/src
Module name:src
Changes by: h...@sourceware.org 2009-07-22 21:30:30

Modified files:
bfd: ChangeLog elflink.c 

Log message:
2009-07-22  H.J. Lu  hongjiu...@intel.com

PR ld/10433
* elflink.c (elf_link_output_extsym): Special case ifunc syms
when ref_regular, not def_regular.

Patches:
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/bfd/ChangeLog.diff?cvsroot=srcr1=1.4696r2=1.4697
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/bfd/elflink.c.diff?cvsroot=srcr1=1.347r2=1.348



-- 


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

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/10433] Latest ld fails to link ldconfig properly

2009-07-22 Thread hjl dot tools at gmail dot com 

--- Additional Comments From hjl dot tools at gmail dot com  2009-07-22 
21:32 ---
I will make a new Linux binutils release today.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/10433] Latest ld fails to link ldconfig properly

2009-07-22 Thread hjl dot tools at gmail dot com 

--- Additional Comments From hjl dot tools at gmail dot com  2009-07-22 
22:18 ---
The Linux binutils 2.19.51.0.14 is released.

-- 


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

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/10433] Latest ld fails to link ldconfig properly

2009-07-22 Thread hjl dot tools at gmail dot com 

--- Additional Comments From hjl dot tools at gmail dot com  2009-07-23 
00:05 ---
Patch is reverted.

-- 
   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/10433] Latest ld fails to link ldconfig properly

2009-07-22 Thread hjl dot tools at gmail dot com 


-- 
   What|Removed |Added

 AssignedTo|hjl dot tools at gmail dot  |unassigned at sources dot
   |com |redhat dot com
 Status|REOPENED|ASSIGNED


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

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils