Re: Bug#585051: (no subject)

2010-06-13 Thread Aurelien Jarno
merge 584778 585051
tag 584778 + fixed-upstream
tag 584778 + patch
thanks

On Sat, Jun 12, 2010 at 08:47:13PM +0200, Matthias Klose wrote:
> On 12.06.2010 19:00, André Wöbbeking wrote:
> >On Saturday 12 June 2010, Aurelien Jarno wrote:
> >
> >>Moreover we can also backport the optimized functions that have been
> >>added in 2.12, but the current goal is to move 2.11 to squeeze, so it
> >>will be for later.
> >>
> >>All that said, I don't plan to disable --with-multi-arch.
> >
> >Aurelien, you mentioned in 583858 that binutils.gold is fixed in experimental
> >(or doesn't trigger this bug). Matthias, could you backport that to Sid?
> 
> I assume that the experimental binutils.gold was tested with glibc
> 2.10.  No, I don't think a backport would be helpful.
> 

You assume wrong, it was tested with glibc 2.11. I don't know if a
backport can be considered helpful or not, but at least it fixes the
problem. Please find the patch attached.

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
#!/bin/sh -e
## 153_gold_pr10893.dpatch
##
## DP: Description: PR gold/10893: Add support for ifunc

if [ $# -ne 1 ]; then
echo >&2 "`basename $0`: script expects -patch|-unpatch as argument"
exit 1
fi

[ -f debian/patches/00patch-opts ] && . debian/patches/00patch-opts
patch_opts="${patch_opts:--f --no-backup-if-mismatch}"

case "$1" in
   -patch) patch $patch_opts -p1 < $0;;
   -unpatch) patch $patch_opts -p1 -R < $0;;
*)
echo >&2 "`basename $0`: script expects -patch|-unpatch as 
argument"
exit 1;;
esac

exit 0

2009-12-07  H.J. Lu  

PR gold/10893
* i386.cc (Target_i386::Scan::globa): Use is_func instead of
checking elfcpp::STT_FUNC.
(Target_i386::Relocate::relocate): Likewise.
* x86_64.cc (Target_x86_64::Scan::global): Likewise.

* symtab.cc (Symbol_table::sized_write_symbol): Turn IFUNC
symbols from shared libraries into normal FUNC symbols.

* symtab.h (Symbol): Add is_func and use it.
--- a/gold/i386.cc
+++ b/gold/i386.cc
@@ -1248,7 +1248,7 @@ Target_i386::Scan::global(Symbol_table* symtab,
   }
 // Make a dynamic relocation if necessary.
 int flags = Symbol::NON_PIC_REF;
-if (gsym->type() == elfcpp::STT_FUNC)
+if (gsym->is_func())
   flags |= Symbol::FUNCTION_CALL;
 if (gsym->needs_dynamic_reloc(flags))
   {
@@ -1727,7 +1727,7 @@ Target_i386::Relocate::relocate(const Relocate_info<32, 
false>* relinfo,
 case elfcpp::R_386_PC32:
   {
 int ref_flags = Symbol::NON_PIC_REF;
-if (gsym != NULL && gsym->type() == elfcpp::STT_FUNC)
+if (gsym != NULL && gsym->is_func())
   ref_flags |= Symbol::FUNCTION_CALL;
 if (should_apply_static_reloc(gsym, ref_flags, true, output_section))
   Relocate_functions<32, false>::pcrel32(view, object, psymval, 
address);
@@ -1743,7 +1743,7 @@ Target_i386::Relocate::relocate(const Relocate_info<32, 
false>* relinfo,
 case elfcpp::R_386_PC16:
   {
 int ref_flags = Symbol::NON_PIC_REF;
-if (gsym != NULL && gsym->type() == elfcpp::STT_FUNC)
+if (gsym != NULL && gsym->is_func())
   ref_flags |= Symbol::FUNCTION_CALL;
 if (should_apply_static_reloc(gsym, ref_flags, false, output_section))
   Relocate_functions<32, false>::pcrel16(view, object, psymval, 
address);
@@ -1759,7 +1759,7 @@ Target_i386::Relocate::relocate(const Relocate_info<32, 
false>* relinfo,
 case elfcpp::R_386_PC8:
   {
 int ref_flags = Symbol::NON_PIC_REF;
-if (gsym != NULL && gsym->type() == elfcpp::STT_FUNC)
+if (gsym != NULL && gsym->is_func())
   ref_flags |= Symbol::FUNCTION_CALL;
 if (should_apply_static_reloc(gsym, ref_flags, false,
  output_section))
--- a/gold/symtab.cc
+++ b/gold/symtab.cc
@@ -2810,11 +2810,16 @@ Symbol_table::sized_write_symbol(
 osym.put_st_size(0);
   else
 osym.put_st_size(sym->symsize());
+  elfcpp::STT type = sym->type();
+  // Turn IFUNC symbols from shared libraries into normal FUNC symbols.
+  if (type == elfcpp::STT_GNU_IFUNC
+  && sym->is_from_dynobj())
+type = elfcpp::STT_FUNC;
   // A version script may have overridden the default binding.
   if (sym->is_forced_local())
-osym.put_st_info(elfcpp::elf_st_info(elfcpp::STB_LOCAL, sym->type()));
+osym.put_st_info(elfcpp::elf_st_info(elfcpp::STB_LOCAL, type));
   else
-osym.put_st_info(elfcpp::elf_st_info(sym->binding(), sym->type()));
+osym.put_st_info(elfcpp::elf_st_info(sym->binding(), type));
   osym.put_st_other(elfcpp::elf_st_other(sym->visibility(), sym->nonvis()));
   osym.put_st_shndx(shndx);
 }
--- a/gold/symtab.h
+++ b/gold/symtab.h
@@ -205,6 +205,14 @@ class Symbol
   type() const
   { return this->type_; }
 
+  // Return true for function symbol.
+  bool
+  is_f

Re: Bug#585051: (no subject)

2010-06-12 Thread Matthias Klose

On 12.06.2010 19:00, André Wöbbeking wrote:

On Saturday 12 June 2010, Aurelien Jarno wrote:


Moreover we can also backport the optimized functions that have been
added in 2.12, but the current goal is to move 2.11 to squeeze, so it
will be for later.

All that said, I don't plan to disable --with-multi-arch.


Aurelien, you mentioned in 583858 that binutils.gold is fixed in experimental
(or doesn't trigger this bug). Matthias, could you backport that to Sid?


I assume that the experimental binutils.gold was tested with glibc 2.10.  No, I 
don't think a backport would be helpful.


  Matthias


--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c13d631.6020...@debian.org



Re: Bug#585051: (no subject)

2010-06-12 Thread André Wöbbeking
On Saturday 12 June 2010, Aurelien Jarno wrote:
 
> Moreover we can also backport the optimized functions that have been
> added in 2.12, but the current goal is to move 2.11 to squeeze, so it
> will be for later.
> 
> All that said, I don't plan to disable --with-multi-arch.

Aurelien, you mentioned in 583858 that binutils.gold is fixed in experimental 
(or doesn't trigger this bug). Matthias, could you backport that to Sid?


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201006121900.51597.woebbek...@web.de



Re: Bug#585051: (no subject)

2010-06-12 Thread Aurelien Jarno
On Sat, Jun 12, 2010 at 03:45:45PM +0200, Matthias Klose wrote:
> On 12.06.2010 15:19, André Wöbbeking wrote:
>> I can confirm this also for C++ programs. It's an interaction of eglibc 2.11 
>> and
>> gold. eglibc 2.10 and gold work together and  eglibc 2.11 without gold also
>> works.
>
> no, it's not 2.11, but 2.11 glibc built --with-multi-arch.  Would the 

I confirm.

> glibc maintainers consider to disable this configure option?  2.11 
> doesn't contain any optimized functions, only 2.12 starts providing these 
> for some architectures.

That's wrong, it does contain some optimized functions (otherwise you
won't have seen this bug). Here is the list:
- strcasestr
- strcpy
- rawmemchr
- strncmp
- strrchr
- stpncpy
- strncpy
- strpbrk
- strspn
- stpncpy
- strlen
- strstr
- strcspn
- strchr
- rindex
- stpcpy
- strcasestr
- rawmemchr
- strcmp
- stpcpy 


Moreover we can also backport the optimized functions that have been
added in 2.12, but the current goal is to move 2.11 to squeeze, so it
will be for later.

All that said, I don't plan to disable --with-multi-arch.

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100612143921.gy21...@hall.aurel32.net



Re: Bug#585051: (no subject)

2010-06-12 Thread Matthias Klose

On 12.06.2010 15:19, André Wöbbeking wrote:

I can confirm this also for C++ programs. It's an interaction of eglibc 2.11 and
gold. eglibc 2.10 and gold work together and  eglibc 2.11 without gold also
works.


no, it's not 2.11, but 2.11 glibc built --with-multi-arch.  Would the glibc 
maintainers consider to disable this configure option?  2.11 doesn't contain any 
optimized functions, only 2.12 starts providing these for some architectures.


  Matthias


--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c138f89.4000...@debian.org