Re: .gnu.warning.foo interferes with archive-member rules
On Mon, Jun 06, 2011 at 03:41:14PM -0700, Roland McGrath wrote:
> Consider:
>
> % head ref.s def.s
> ==> ref.s <==
> .data
> ptrsym:
> .long badsym
>
> .section .gnu.warning.badsym,"",@progbits
> .string "badsym warning"
>
> ==> def.s <==
> .comm badsym,4
> % as --32 -o ref.o ref.s
> % as --32 -o def.o def.s
> % ar cqs def.a def.o
> % ./ld/ld-new -m elf_i386 -o foo ref.o def.a
> ref.o: In function `ptrsym':
> (.data+0x0): warning: badsym warning
> ./ld/ld-new: warning: cannot find entry symbol _start; defaulting to
> 08048054
> ref.o: In function `ptrsym':
> (.data+0x0): undefined reference to `badsym'
> [Exit 1]
> %
I think you've managed to hit two bugs. I'll commit the following
after some testing.
bfd/
* elflink.c (_bfd_elf_archive_symbol_lookup): Follow warning and
indirect links here.
ld/
* ldlang.c (lang_one_common): Handle warning symbols.
Index: bfd/elflink.c
===
RCS file: /cvs/src/src/bfd/elflink.c,v
retrieving revision 1.406
diff -u -p -r1.406 elflink.c
--- bfd/elflink.c 26 May 2011 04:28:20 - 1.406
+++ bfd/elflink.c 7 Jun 2011 09:03:39 -
@@ -4911,7 +4911,7 @@ _bfd_elf_archive_symbol_lookup (bfd *abf
char *p, *copy;
size_t len, first;
- h = elf_link_hash_lookup (elf_hash_table (info), name, FALSE, FALSE, FALSE);
+ h = elf_link_hash_lookup (elf_hash_table (info), name, FALSE, FALSE, TRUE);
if (h != NULL)
return h;
@@ -4934,14 +4934,14 @@ _bfd_elf_archive_symbol_lookup (bfd *abf
memcpy (copy, name, first);
memcpy (copy + first, name + first + 1, len - first);
- h = elf_link_hash_lookup (elf_hash_table (info), copy, FALSE, FALSE, FALSE);
+ h = elf_link_hash_lookup (elf_hash_table (info), copy, FALSE, FALSE, TRUE);
if (h == NULL)
{
/* We also need to check references to the symbol without the
version. */
copy[first - 1] = '\0';
h = elf_link_hash_lookup (elf_hash_table (info), copy,
- FALSE, FALSE, FALSE);
+ FALSE, FALSE, TRUE);
}
bfd_release (abfd, copy);
Index: ld/ldlang.c
===
RCS file: /cvs/src/src/ld/ldlang.c,v
retrieving revision 1.370
diff -u -p -r1.370 ldlang.c
--- ld/ldlang.c 23 May 2011 05:41:01 - 1.370
+++ ld/ldlang.c 7 Jun 2011 09:03:41 -
@@ -5885,6 +5885,9 @@ lang_one_common (struct bfd_link_hash_en
bfd_vma size;
asection *section;
+ if (h->type == bfd_link_hash_warning)
+h = h->u.i.link;
+
if (h->type != bfd_link_hash_common)
return TRUE;
--
Alan Modra
Australia Development Lab, IBM
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
More complete fix for a previous problem in gprof.
Here is a patch to correct a previous gprof bug that was only partially
fixed. Apparently it is possible for GCC to clone its own cloned
functions.
This problem manifested in a large g++ application which I cannot
provide in source form. Furthermore, simplification of that example
eliminates the problem with high probability. The best evidence I can
provide is the following gdb session showing the boundary between two
functions that demonstrates such a "clone of a clone":
(gdb) x/5i 0x7a7ae8
0x7a7ae8 <_ZN10sims_Event15startSimulationEv+552>:
callq 0x7a6f40 <_ZN19trno_WarningMessagelsEPKc.clone.4>
0x7a7aed <_ZN10sims_Event15startSimulationEv+557>:
jmp0x7a7ab8 <_ZN10sims_Event15startSimulationEv+504>
0x7a7aef: nop
0x7a7af0
<_ZNKSt6vectorIPN10sims_Event9EventLinkESaIS2_EE12_M_check_lenEmPKc.clone.45.clone.53>:
push %rbp
0x7a7af1
<_ZNKSt6vectorIPN10sims_Event9EventLinkESaIS2_EE12_M_check_lenEmPKc.clone.45.clone.53+1>:
mov%rsp,%rbp
(gdb)
Note the .clone.45.clone.53 suffix on the symbol.
The following patch accepts function symbols that match the following
extended regular expression:
^[^\$\.]*(\.(clone\.)?[0-9]+)+$
and so accepts the following symbols:
foo.123
foo.clone.23
foo.clone.1.clone.2
foo.2.clone.6.clone.9
foo.2.1.clone.3.4.clone.5
This errs on the side of accepting more cases than the relevent
mechanisms are likely to produce (e.g., the last example).
David
--- orig/gprof/corefile.c 2011-06-06 10:07:57.406964819 -0400
+++ fixed/gprof/corefile.c 2011-06-06 10:15:10.198544726 -0400
@@ -389,16 +389,21 @@
if (*name == '.')
{
- /* Allow GCC cloned functions. */
- if (strlen (name) > 7 && strncmp (name, ".clone.", 7) == 0)
- name += 6;
-
- /* Do not discard nested subprograms (those
-which end with .NNN, where N are digits). */
- for (name++; *name; name++)
- if (! ISDIGIT (*name))
+ /* Allow both nested subprograms and GCC cloned functions.
+Apparently, GCC can clone both of these. */
+ do {
+ if (strlen (name) > 7 && strncmp (name, ".clone.", 7) == 0)
+ name += 6;
+ int digit_seen = 0;
+ /* Do not discard nested subprograms (those
+ which end with .NNN, where N are digits). */
+ for (name++; *name; name++)
+ if (digit_seen && *name == '.') break;
+ else if (ISDIGIT (*name))
+ digit_seen = 1;
+ else
return 0;
-
+ } while (*name == '.');
break;
}
}
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
Re: More complete fix for a previous problem in gprof.
Hi David,
Here is a patch to correct a previous gprof bug that was only partially
fixed. Apparently it is possible for GCC to clone its own cloned
functions.
Thanks for submitting this patch. I have tidied it up slightly and
applied it to the sources along with this changelog entry.
Cheers
Nick
gprof/ChangeLog
2011-06-07 David Warme
* corefile.c (core_sym_class): Allow for multiple iterations of
clone clones and subprograms.
Index: gprof/corefile.c
===
RCS file: /cvs/src/src/gprof/corefile.c,v
retrieving revision 1.42
diff -u -3 -p -r1.42 corefile.c
--- gprof/corefile.c 28 Feb 2011 18:36:14 - 1.42
+++ gprof/corefile.c 7 Jun 2011 13:33:05 -
@@ -387,19 +387,27 @@ core_sym_class (asymbol *sym)
if (*name == '$')
return 0;
- if (*name == '.')
+ while (*name == '.')
{
- /* Allow GCC cloned functions. */
- if (strlen (name) > 7 && strncmp (name, ".clone.", 7) == 0)
- name += 6;
+ /* Allow both nested subprograms (which end with ".NNN", where N is
+ a digit) and GCC cloned functions (which contain ".clone").
+ Allow for multiple iterations of both - apparently GCC can clone
+ clones and subprograms. */
+ int digit_seen = 0;
+#define CLONE_NAME ".clone."
+#define CLONE_NAME_LEN strlen (CLONE_NAME)
+
+ if (strlen (name) > CLONE_NAME_LEN
+ && strncmp (name, CLONE_NAME, CLONE_NAME_LEN) == 0)
+ name += CLONE_NAME_LEN - 1;
- /* Do not discard nested subprograms (those
- which end with .NNN, where N are digits). */
for (name++; *name; name++)
- if (! ISDIGIT (*name))
+ if (digit_seen && *name == '.')
+ break;
+ else if (ISDIGIT (*name))
+ digit_seen = 1;
+ else
return 0;
-
- break;
}
}
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/12854] New: ARM: Nonsensical argument shift specifications accepted for LSL/LSR/ASR/ROR mnemonics
http://sourceware.org/bugzilla/show_bug.cgi?id=12854 Summary: ARM: Nonsensical argument shift specifications accepted for LSL/LSR/ASR/ROR mnemonics Product: binutils Version: 2.22 (HEAD) Status: NEW Severity: normal Priority: P2 Component: gas AssignedTo: unassig...@sources.redhat.com ReportedBy: dave.mar...@linaro.org gas accepts a trailing ", " for LSL/LSR/ASR/ROR instructions, but this is invalid syntax. The shift specification appears to be ignored, with no effect on the assembly; rather, this trailing junk should be rejected with an error: Observed on trunk, 20110606: binutils$ gas/as-new -o tst.o <: 0: e1a00251asr r0, r1, r2 4: e1a00271ror r0, r1, r2 -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/12854] ARM: Nonsensical argument shift specifications accepted for LSL/LSR/ASR/ROR mnemonics
http://sourceware.org/bugzilla/show_bug.cgi?id=12854 Dave Martin changed: What|Removed |Added CC||mgretton at sourceware dot ||org -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/12855] New: readelf: Endless loop for broken ELF binary
http://sourceware.org/bugzilla/show_bug.cgi?id=12855 Summary: readelf: Endless loop for broken ELF binary Product: binutils Version: 2.21 Status: NEW Severity: normal Priority: P2 Component: binutils AssignedTo: unassig...@sources.redhat.com ReportedBy: sasc...@gmx.de Commandline: $ readelf -s godoc Goes into an endless loop with the following output: readelf: Error: Unable to seek to 0xYYY for version need aux (3) ... Ideally, readelf would stop and tell it's a broken binary (see attachment). -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/12855] readelf: Endless loop for broken ELF binary
http://sourceware.org/bugzilla/show_bug.cgi?id=12855 --- Comment #1 from Sascha Peilicke 2011-06-07 15:39:05 UTC --- Created attachment 5770 --> http://sourceware.org/bugzilla/attachment.cgi?id=5770 The offending binary (packed) -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
Re: .gnu.warning.foo interferes with archive-member rules
Thanks! I don't understand your changes at all off hand, and I strongly suspected that the patch I tried was too simple-minded to be right. Thanks, Roland ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
Re: .gnu.warning.foo interferes with archive-member rules
On Tue, Jun 07, 2011 at 09:50:18AM -0700, Roland McGrath wrote: > Thanks! I don't understand your changes at all off hand, and I strongly > suspected that the patch I tried was too simple-minded to be right. Setting "follow" true for the elf_link_hash_lookup calls in _bfd_elf_archive_symbol_lookup means we get to the real symbol in the elf_link_add_archive_symbols loop you were patching. We want that because elf_link_add_archive_symbols needs to make a decision depending on whether the symbol is defined or not, and specially treat commons. Indirect and warning syms can point to any other sym type. The lang_one_common change is needed in any function called by bfd_link_hash_traverse. When warning symbols are created, they replace the "real" entry in the hash table, so you never get to see the real symbol in a hash traversal. -- Alan Modra Australia Development Lab, IBM ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
Re: .gnu.warning.foo interferes with archive-member rules
On Tue, Jun 7, 2011 at 2:08 AM, Alan Modra wrote:
> On Mon, Jun 06, 2011 at 03:41:14PM -0700, Roland McGrath wrote:
>> Consider:
>>
>> % head ref.s def.s
>> ==> ref.s <==
>> .data
>> ptrsym:
>> .long badsym
>>
>> .section .gnu.warning.badsym,"",@progbits
>> .string "badsym warning"
>>
>> ==> def.s <==
>> .comm badsym,4
>> % as --32 -o ref.o ref.s
>> % as --32 -o def.o def.s
>> % ar cqs def.a def.o
>> % ./ld/ld-new -m elf_i386 -o foo ref.o def.a
>> ref.o: In function `ptrsym':
>> (.data+0x0): warning: badsym warning
>> ./ld/ld-new: warning: cannot find entry symbol _start; defaulting to
>> 08048054
>> ref.o: In function `ptrsym':
>> (.data+0x0): undefined reference to `badsym'
>> [Exit 1]
>> %
>
> I think you've managed to hit two bugs. I'll commit the following
> after some testing.
>
> bfd/
> * elflink.c (_bfd_elf_archive_symbol_lookup): Follow warning and
> indirect links here.
> ld/
> * ldlang.c (lang_one_common): Handle warning symbols.
>
I checked in this testcase.
Thanks.
--
H.J.
---
diff --git a/ld/testsuite/ChangeLog b/ld/testsuite/ChangeLog
index 5ee6f44..31d542d 100644
--- a/ld/testsuite/ChangeLog
+++ b/ld/testsuite/ChangeLog
@@ -1,3 +1,11 @@
+2011-06-07 H.J. Lu
+
+ * ld-elf/elf.exp: Build symbol3.a and symbol3w.a.
+
+ * ld-elf/symbol3.s: New.
+ * ld-elf/symbol3w.s: Likewise.
+ * ld-elf/warn3.d: Likewise.
+
2011-06-02 Nathan Sidwell
Adjust tests for zero offset formatting.
diff --git a/ld/testsuite/ld-elf/elf.exp b/ld/testsuite/ld-elf/elf.exp
index b9ff0bd..e991f83 100644
--- a/ld/testsuite/ld-elf/elf.exp
+++ b/ld/testsuite/ld-elf/elf.exp
@@ -40,6 +40,15 @@ if { [is_remote host] } then {
remote_download host merge.ld
}
+run_ld_link_tests {
+{"Build symbol3.a"
+ "" ""
+ {symbol3.s} {} "symbol3.a"}
+{"Build symbol3w.a"
+ "" ""
+ {symbol3w.s} {} "symbol3w.a"}
+}
+
set test_list [lsort [glob -nocomplain $srcdir/$subdir/*.d]]
foreach t $test_list {
# We need to strip the ".d", but can leave the dirname.
diff --git a/ld/testsuite/ld-elf/symbol3.s b/ld/testsuite/ld-elf/symbol3.s
new file mode 100644
index 000..4fd76d5
--- /dev/null
+++ b/ld/testsuite/ld-elf/symbol3.s
@@ -0,0 +1 @@
+.comm badsym,4
diff --git a/ld/testsuite/ld-elf/symbol3w.s b/ld/testsuite/ld-elf/symbol3w.s
new file mode 100644
index 000..33262a6
--- /dev/null
+++ b/ld/testsuite/ld-elf/symbol3w.s
@@ -0,0 +1,4 @@
+ .data
+ .dc.a badsym
+.section.gnu.warning.badsym,"",%progbits
+.string "badsym warning"
diff --git a/ld/testsuite/ld-elf/warn3.d b/ld/testsuite/ld-elf/warn3.d
new file mode 100644
index 000..c99618d
--- /dev/null
+++ b/ld/testsuite/ld-elf/warn3.d
@@ -0,0 +1,15 @@
+#source: start.s
+#ld: tmpdir/symbol3w.o tmpdir/symbol3.a
+#warning: .*: warning: badsym warning$
+#readelf: -s
+#notarget: "sparc64-*-solaris2*" "sparcv9-*-solaris2*"
+#xfail: arc-*-* d30v-*-* dlx-*-* fr30-*-* frv-*-elf i860-*-* i960-*-*
+#xfail: iq*-*-* mn10200-*-* moxie-*-* msp*-*-* mt-*-* or32-*-* pj*-*-*
+# if not using elf32.em, you don't get fancy section handling
+
+# Check that warnings are generated for the symbols in .gnu.warning
+# construct and that the symbol still appears as expected.
+
+#...
+ +[0-9]+: +[0-9a-f]+ +4 +OBJECT +GLOBAL +DEFAULT +[1-9] badsym
+#pass
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
