[Bug gold/11694] New: Statically linked programs trying to dlopen themselves hang when linked with gold
When using gold (Last tested version: GNU gold (Linux/GNU Binutils 2.20.51.0.9.20100526) 1.9), the check done in various autoconf scripts (checking whether a statically linked program can dlopen itself) hangs forever, with conftest taking up 100% CPU time. Switching the linker to the old ld fixes it. More information on the issue (including the theory that it is related to gold's handling of STT_GNU_IFUNC symbols) can be found at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=584607 -- Summary: Statically linked programs trying to dlopen themselves hang when linked with gold Product: binutils Version: 2.20 Status: NEW Severity: normal Priority: P2 Component: gold AssignedTo: ian at airs dot com ReportedBy: bero at arklinux dot org CC: bug-binutils at gnu dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://sourceware.org/bugzilla/show_bug.cgi?id=11694 --- 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 gold/11694] Statically linked programs trying to dlopen themselves hang when linked with gold
--- Additional Comments From ian at airs dot com 2010-06-11 13:10 --- gold does not yet support STT_GNU_IFUNC symbols at all. -- What|Removed |Added Status|NEW |ASSIGNED http://sourceware.org/bugzilla/show_bug.cgi?id=11694 --- 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
[ARM/THUMB] Incorrect branch generated for long calls
Hi, I just met a possible bug in binutils 2.20.1 when mixing ARM/Thumb code under some conditions. I wouldn't mind a confirmation that it's a real bug before opening an entry in bugzilla. This happens when the target function is: - ARM (32bits) code - not accessible with a short call (B or BL instruction) - called from Thumb at some place - called from ARM at some other place (and here the bug happens) ld inserts a __func_from_thumb veneer to be called by Thumb code, but this veneer is also called from ARM code, while ARM code should use a different veneer. (or even point directly to the ARM code of the veneer, after "bx pc" and "nop") I've attached a small commented test case: Just put the 4 files somewhere, edit Makefile to match your ARM compiler and run make test to build, link, and print commented objdump disassembly (look for "BUG" in the output). The linker script is necessary to put the function out of reach from short calls, I met the bug when building rockbox on targets with different RAMs which can't access each other with a short call (and there's no MMU on these devices to remap the memory regions close to each other). I had a look at bfd/elf32-arm.c but it's just too long for me to handle :) thanks -- Rafaël Carré f.i Description: Binary data Makefile Description: Binary data start.i Description: Binary data test.lds Description: Binary data signature.asc Description: PGP signature ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [ARM/THUMB] Incorrect branch generated for long calls
On Jun 11, 2010, at 4:26 PM, Matthew Gretton-Dann wrote: > On Fri, 2010-06-11 at 15:35 +0200, Rafaël Carré wrote: >> Hi, >> >> I just met a possible bug in binutils 2.20.1 when mixing ARM/Thumb code >> under some conditions. >> >> I wouldn't mind a confirmation that it's a real bug before opening an >> entry in bugzilla. > > This is indeed a bug in binutils 2.20.1. However, it has already been > fixed in trunk binutils. > > If binutils 2.20.2 was to be released I would consider backporting a > fix. However, I believe the next release of binutils will be 2.21 which > will have this fix in. Feel free to backport it in the 2.20 branch. > Tristan will be able to state what the next release of binutils will be. There is no plan for a binutils 2.20.2. The next release, binutils 2.21 is planed for October. Tristan. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [ARM/THUMB] Incorrect branch generated for long calls
On 11.06.2010 15:35, Rafaël Carré wrote: Hi, I just met a possible bug in binutils 2.20.1 when mixing ARM/Thumb code under some conditions. I wouldn't mind a confirmation that it's a real bug before opening an entry in bugzilla. Thanks for the detailed report. It looks like this bug has been fixed in the CVS trunk (see patch http://sourceware.org/ml/binutils/2010-02/msg00460.html), just a bit too late to make it into release 2.20.1. (I have checked that with the current trunk it's OK) Maybe you can the patch to your sources? Christophe. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [ARM/THUMB] Incorrect branch generated for long calls
On Fri, 2010-06-11 at 15:35 +0200, Rafaël Carré wrote: > Hi, > > I just met a possible bug in binutils 2.20.1 when mixing ARM/Thumb code > under some conditions. > > I wouldn't mind a confirmation that it's a real bug before opening an > entry in bugzilla. This is indeed a bug in binutils 2.20.1. However, it has already been fixed in trunk binutils. If binutils 2.20.2 was to be released I would consider backporting a fix. However, I believe the next release of binutils will be 2.21 which will have this fix in. Tristan will be able to state what the next release of binutils will be. Thanks, Matt -- Matthew Gretton-Dann Principal Engineer - PDSW Tools ARM Ltd ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [ARM/THUMB] Incorrect branch generated for long calls
On Fri, 11 Jun 2010 15:26:14 +0100 Matthew Gretton-Dann wrote: > On Fri, 2010-06-11 at 15:35 +0200, Rafaël Carré wrote: > > Hi, > > > > I just met a possible bug in binutils 2.20.1 when mixing ARM/Thumb > > code under some conditions. > > > > I wouldn't mind a confirmation that it's a real bug before opening > > an entry in bugzilla. > > This is indeed a bug in binutils 2.20.1. However, it has already been > fixed in trunk binutils. Thanks, next time I will listen a bit more to the little voice who says "test the trunk before reporting bugs" ;-) I'll backport the patch to 2.20.1 like Christophe suggested and wait for the next release -- Rafaël Carré signature.asc Description: PGP signature ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [ARM/THUMB] Incorrect branch generated for long calls
On Fri, 11 Jun 2010 16:29:55 +0200
Tristan Gingold wrote:
>
> On Jun 11, 2010, at 4:26 PM, Matthew Gretton-Dann wrote:
>
> > On Fri, 2010-06-11 at 15:35 +0200, Rafaël Carré wrote:
> >> Hi,
> >>
> >> I just met a possible bug in binutils 2.20.1 when mixing ARM/Thumb
> >> code under some conditions.
> >>
> >> I wouldn't mind a confirmation that it's a real bug before opening
> >> an entry in bugzilla.
> >
> > This is indeed a bug in binutils 2.20.1. However, it has already
> > been fixed in trunk binutils.
> >
> > If binutils 2.20.2 was to be released I would consider backporting a
> > fix. However, I believe the next release of binutils will be 2.21
> > which will have this fix in.
>
> Feel free to backport it in the 2.20 branch.
Just in case someone needs it, here it is (I didn't modify the tests)
--
Rafaël Carré
http://sourceware.org/ml/binutils/2010-02/msg00460.html
diff -ur binutils-2.20.1.orig/bfd/elf32-arm.c binutils-2.20.1/bfd/elf32-arm.c
--- binutils-2.20.1.orig/bfd/elf32-arm.c 2010-06-11 18:48:06.0 +0200
+++ binutils-2.20.1/bfd/elf32-arm.c 2010-06-11 18:51:00.0 +0200
@@ -2401,6 +2401,7 @@
unsigned long orig_insn;
char *stub_name;
enum elf32_arm_stub_type stub_type;
+ int st_type;
};
/* A table of relocs applied to branches which might trigger Cortex-A8
@@ -2647,6 +2648,9 @@
asection *stub_sec;
} *stub_group;
+ /* Number of elements in stub_group. */
+ int top_id;
+
/* Assorted information used by elf32_arm_size_stubs. */
unsigned int bfd_count;
int top_index;
@@ -2933,6 +2937,7 @@
ret->add_stub_section = NULL;
ret->layout_sections_again = NULL;
ret->stub_group = NULL;
+ ret->top_id = 0;
ret->bfd_count = 0;
ret->top_index = 0;
ret->input_list = NULL;
@@ -3033,7 +3038,7 @@
arm_type_of_stub (struct bfd_link_info *info,
asection *input_sec,
const Elf_Internal_Rela *rel,
- unsigned char st_type,
+ int *actual_st_type,
struct elf32_arm_link_hash_entry *hash,
bfd_vma destination,
asection *sym_sec,
@@ -3048,6 +3053,7 @@
int thumb_only;
enum elf32_arm_stub_type stub_type = arm_stub_none;
int use_plt = 0;
+ int st_type = *actual_st_type;
/* We don't know the actual type of destination in case it is of
type STT_SECTION: give up. */
@@ -3065,14 +3071,15 @@
+ input_sec->output_section->vma
+ rel->r_offset);
- branch_offset = (bfd_signed_vma)(destination - location);
-
r_type = ELF32_R_TYPE (rel->r_info);
/* Keep a simpler condition, for the sake of clarity. */
- if (globals->splt != NULL && hash != NULL && hash->root.plt.offset != (bfd_vma) -1)
+ if (globals->splt != NULL
+ && hash != NULL
+ && hash->root.plt.offset != (bfd_vma) -1)
{
use_plt = 1;
+
/* Note when dealing with PLT entries: the main PLT stub is in
ARM mode, so if the branch is in Thumb mode, another
Thumb->ARM stub will be inserted later just before the ARM
@@ -3081,8 +3088,15 @@
Thumb->Arm one and branch directly to the ARM PLT entry
because it avoids spreading offset corrections in several
places. */
+
+ destination = (globals->splt->output_section->vma
+ + globals->splt->output_offset
+ + hash->root.plt.offset);
+ st_type = STT_FUNC;
}
+ branch_offset = (bfd_signed_vma)(destination - location);
+
if (r_type == R_ARM_THM_CALL || r_type == R_ARM_THM_JUMP24)
{
/* Handle cases where:
@@ -3176,7 +3190,9 @@
}
}
}
- else if (r_type == R_ARM_CALL || r_type == R_ARM_JUMP24 || r_type == R_ARM_PLT32)
+ else if (r_type == R_ARM_CALL
+ || r_type == R_ARM_JUMP24
+ || r_type == R_ARM_PLT32)
{
if (st_type == STT_ARM_TFUNC)
{
@@ -3231,6 +3247,12 @@
}
}
+ /* If a stub is needed, record the actual destination type. */
+ if (stub_type != arm_stub_none)
+{
+ *actual_st_type = st_type;
+}
+
return stub_type;
}
@@ -3240,31 +3262,35 @@
elf32_arm_stub_name (const asection *input_section,
const asection *sym_sec,
const struct elf32_arm_link_hash_entry *hash,
- const Elf_Internal_Rela *rel)
+ const Elf_Internal_Rela *rel,
+ enum elf32_arm_stub_type stub_type)
+
{
char *stub_name;
bfd_size_type len;
if (hash)
{
- len = 8 + 1 + strlen (hash->root.root.root.string) + 1 + 8 + 1;
+ len = 8 + 1 + strlen (hash->root.root.root.string) + 1 + 8 + 1 + 2 + 1;
stub_name = bfd_malloc (len);
if (stub_name != NULL)
- sprintf (stub_name, "%08x_%s+%x",
+ sprintf (stub_name, "%08x_%s+%x_%d",
input_section->id & 0x,
hash->root.root.root.string,
- (int) rel->r_addend & 0x);
+ (int) rel->r_addend & 0x,
+ (int) stub_type);
}
else
{
- len = 8 + 1 + 8 + 1 + 8 + 1 + 8 + 1;
+ len = 8 + 1 + 8 + 1 + 8 + 1 + 8 + 1 + 2 + 1;
stub_name = bfd_malloc (len);
if (stub_name != NULL)
- sprintf (stub_name, "%08x_%x:%x+%x",
+ spri
