[Bug gas/19498] Invalid "symbol definition loop encountered at `callmealias.lto_priv.1'" diagnostics for weakrefs
https://sourceware.org/bugzilla/show_bug.cgi?id=19498 --- Comment #4 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=22987cec624a7890637aa9d8760fbeaeb45a0e20 commit 22987cec624a7890637aa9d8760fbeaeb45a0e20 Author: Alan Modra Date: Mon Apr 4 16:19:27 2016 +0930 PR19498, Invalid "symbol definition loop" PR 19498 * symbols.c (resolve_symbol_value): Clear sy_resolving on exit from function on all paths that set sy_resolving. -- 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/19498] Invalid "symbol definition loop encountered at `callmealias.lto_priv.1'" diagnostics for weakrefs
https://sourceware.org/bugzilla/show_bug.cgi?id=19498 Alan Modra changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Alan Modra --- Fixed mainline -- 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/19872] nm and probably addr2line can't handle binaries produced with gold --incremental
https://sourceware.org/bugzilla/show_bug.cgi?id=19872 --- Comment #6 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Nick Clifton : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=67f101eece4327a7c9e13f257fe76f8082a5e336 commit 67f101eece4327a7c9e13f257fe76f8082a5e336 Author: Nick Clifton Date: Mon Apr 4 12:53:33 2016 +0100 Ignore DWARF debug information with a version of 0 - assume that it is padding. PR 19872 bfd * dwarf2.c (parse_comp_unit): Skip warning about unrecognised version number if the version is zero. bin * dwarf.c (display_debug_aranges): Skip warning about unrecognised version number if the version is zero. -- 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/19872] nm and probably addr2line can't handle binaries produced with gold --incremental
https://sourceware.org/bugzilla/show_bug.cgi?id=19872 Nick Clifton changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Nick Clifton --- Patch checked in. If the problem resurfaces, then please reopen this PR. Cheers Nick -- 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/19872] nm and probably addr2line can't handle binaries produced with gold --incremental
https://sourceware.org/bugzilla/show_bug.cgi?id=19872 gingold at adacore dot com changed: What|Removed |Added CC||gingold at adacore dot com --- Comment #8 from gingold at adacore dot com --- Nick, you have committed unrelated chunks (pe-dll, aarch64/simulator.c) Tristan. -- 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 ld/19803] gc-sections breaks PE DLL variable export
https://sourceware.org/bugzilla/show_bug.cgi?id=19803 --- Comment #22 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Nick Clifton : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=a061de07e441718d3658be332fd3172d87c7440b commit a061de07e441718d3658be332fd3172d87c7440b Author: Nick Clifton Date: Mon Apr 4 13:44:57 2016 +0100 More fixes for COFF/PE lanker garbage collection. PR 19803 * emultempl/pe.em (change_undef): New function. Encapsulates duplicated code in pe_fixup_stdcalls and adds the newly defined sym to the gc root list. (pe_fixup_stdcall): Use the new function. * pe-dll.c (process_def_file_and_drectve); Add alias of exported symbol to gc root list. -- 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 gprof/19904] New: SIGPROF keeps a large task from ever completing a fork()
https://sourceware.org/bugzilla/show_bug.cgi?id=19904
Bug ID: 19904
Summary: SIGPROF keeps a large task from ever completing a
fork()
Product: binutils
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: gprof
Assignee: unassigned at sourceware dot org
Reporter: paulo.cesar.pereira.de.andrade at gmail dot com
Target Milestone: ---
A program can be built to cause a -pg built binary to enter
an infinite loop in fork call, due to not finishing the
syscall before the signal is sent again, entering an infinite
loop restarting the syscall.
Testing user provided test case:
"""
# cat test.cpp
#include
#include
#include
int main(int argc, char ** argv)
{
int a1l, a2l, i, j, pid;
double ** p;
double * q;
a1l = atoi(argv[1]);
a2l = atoi(argv[2]);
p = (double**)malloc(a1l * sizeof(double*));
for (i = 0; i < a1l; i++) {
q = (double*)malloc(a2l * sizeof(double));
for (j = 0; j < a2l; j++) q[j] = (double) j;
p[i] = q;
}
printf("Forking!\n"); fflush(stdout);
pid = fork();
printf("Fork returns...\n");
switch (pid) {
case -1:
printf("Parent: fork failed\n"); perror("fork");
break;
case 0:
printf("Son: fork succeeded, pid = %d\n", getpid());
break;
default:
printf("Parent: fork succeeded, pid = %d\n", pid);
}
return 0;
}
# g++ -o ./test -g -pg -Wunused -Wall test.cpp
# ./bin/test 1000 20
"""
Previously RHEL5 had a patch to workaround it, to the
correct gprof issue in kernel:
"""
commit 122c17ac54c9b3f53e80bc6f0786cc5f2a8dc486
Author: Stefan Ring
Date: Fri May 8 13:19:55 2015 +0200
the patch (v2.6.18)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 34ed0d9..808f79d 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1478,6 +1478,7 @@ static inline int lock_need_resched(spinlock_t *lock)
extern FASTCALL(void recalc_sigpending_tsk(struct task_struct *t));
extern void recalc_sigpending(void);
+extern int fork_recalc_sigpending(void);
extern void signal_wake_up(struct task_struct *t, int resume_stopped);
diff --git a/kernel/fork.c b/kernel/fork.c
index f9b014e..21f9a0d 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1193,8 +1193,7 @@ static struct task_struct *copy_process(unsigned long
clone_flags,
* A fatal signal pending means that current will exit, so the new
* thread can't slip out of an OOM kill (or normal SIGKILL).
*/
- recalc_sigpending();
- if (signal_pending(current)) {
+ if (fork_recalc_sigpending()) {
spin_unlock(¤t->sighand->siglock);
write_unlock_irq(&tasklist_lock);
retval = -ERESTARTNOINTR;
diff --git a/kernel/signal.c b/kernel/signal.c
index bfdb568..bd7e794 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -227,6 +227,31 @@ void recalc_sigpending(void)
recalc_sigpending_tsk(current);
}
+int fork_recalc_sigpending(void)
+{
+ struct task_struct *tsk = current;
+ int pending;
+
+ recalc_sigpending();
+ if (likely(!signal_pending(tsk)))
+ return 0;
+
+ pending = 1;
+ /*
+* HACK. If SIGPROF is the sole reason for TIF_SIGPENDING
+* we assume it was sent by ITIMER_PROF and return false,
+* otherwise fork() can never succeed if it takes more than
+* it_prof_incr. bz645528.
+*/
+ if (!sigismember(&tsk->blocked, SIGPROF)) {
+ sigaddset(&tsk->blocked, SIGPROF);
+ pending = recalc_sigpending_tsk(tsk);
+ sigdelset(&tsk->blocked, SIGPROF);
+ }
+
+ return pending;
+}
+
/* Given the mask, find the first available signal that should be serviced. */
static int
"""
This patch/hack is not in upstream neither in newer RHEL.
Users were suggested to switch to perf, but gprof should
be still an useful tool, e.g. for non x86 architectures.
It was suggested to block SIGPROF during the clone syscall
in glibc, but that would become overkill as well.
The proper solution should be to applications built with
-pg to somehow block it, and likely, have an option of
which syscalls to block, in case syscalls other than clone
could cause the infinite loop.
--
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 gprof/19904] SIGPROF keeps a large task from ever completing a fork()
https://sourceware.org/bugzilla/show_bug.cgi?id=19904 Carlos O'Donell changed: What|Removed |Added Status|NEW |RESOLVED CC||carlos at redhat dot com Resolution|--- |WONTFIX --- Comment #1 from Carlos O'Donell --- I am going to go as far as to say this can't be fixed. In userspace neither the compiler nor the static linker knows what a "syscall" is and therefore can't wrap the syscall with SIGPROF mask/unmask operations. Only glibc knows what a "syscall" is and if we mask/unmask SIGPROF around such syscalls you would loose all profiling for signal handlers, and worse if the signal handler longjmp'd (allowed by POSIX) you would loose profiling for the rest of program. Only the kernel knows that it's in the middle of clone, fork, or other syscalls (see in_syscall usage by some arches) and avoid delivering a SIGPROF signal because doing so would interrupt the syscall and lead to a restart loop. I think it might be OK for the kernel to block SIGPROF during syscall operation because SIGPROF is only designed to be used to instrument userspace code and the kernel code can be considered to have taken zero time to execute. I see that as the only solution to this problem. I'm going to mark this as resolved/wontfix for binutils since they can't solve it. Please file a bug with the upstream kernel tracker. -- 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 gprof/19904] SIGPROF keeps a large task from ever completing a fork()
https://sourceware.org/bugzilla/show_bug.cgi?id=19904 Florian Weimer changed: What|Removed |Added CC||fweimer at redhat dot com -- 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 ld/19908] New: MIPS/ELF: Hidden and internal dynamic symbols produced
https://sourceware.org/bugzilla/show_bug.cgi?id=19908
Bug ID: 19908
Summary: MIPS/ELF: Hidden and internal dynamic symbols produced
Product: binutils
Version: 2.27 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: ma...@linux-mips.org
Reporter: ma...@linux-mips.org
Target Milestone: ---
Target: mips-linux-gnu
It is required by the the ELF gABI[1] that hidden and internal symbols
must not appear in the dynamic symbol table:
"A hidden symbol contained in a relocatable object must be either
removed or converted to STB_LOCAL binding by the link-editor when the
relocatable object is included in an executable file or shared object."
"An internal symbol contained in a relocatable object must be either
removed or converted to STB_LOCAL binding by the link-editor when the
relocatable object is included in an executable file or shared object."
The ELF linker usually respects this requirement, however in the case
where a dynamic symbol has been preallocated due to a reference of the
default export class aka visibility from the object being linked, and
then merged with a hidden or internal symbol definition from within the
same object, then the original export class is carried over to the
output dynamic symbol table, because while merging the generic ELF
linker only converts affected dynamic symbols to local when they are
defined or referenced by the object being linked and a dynamic object
involved in the link both at a time.
The dynamic symbol produced confuses then the dynamic loader at the run
time -- the hidden or internal export class is ignored and the symbol
follows preemption rules as with the default export class.
In the MIPS target it happens when `mips_elf_record_global_got_symbol'
creates a dynamic symbol when a call relocation is encountered.
Additionally if the undefined symbol referred by such a relocation does
specify the intended export class, then a local dynamic symbol is
created instead, which is harmless and allowed, but useless. Normally
no local dynamic symbols are created, except for a single dummy one at
the beginning.
This can be reproduced with these simple C sources (bash syntax):
$ cat f0.c
#include
int f1 (void);
int f2 (void);
int
main (void)
{
printf ("%d\n", f1 ());
printf ("%d\n", f2 ());
return 0;
}
$ cat f1.c
int
f1 (void)
{
return 1;
}
$ cat f2.c
int
f1 (void)
{
return 2;
}
int
f2 (void)
{
return f1 ();
}
$ mips-linux-gnu-gcc -fPIC -c f0.c
$ mips-linux-gnu-gcc -fPIC -fvisibility=hidden -c f1.c
$ mips-linux-gnu-gcc -fPIC -c f2.c
$ mips-linux-gnu-gcc -fPIC -shared -Wl,-soname,libf2.so -o libf2.so f2.o
$ mips-linux-gnu-gcc -Wl,-rpath,$(pwd) -L$(pwd) -o f f0.o f1.o -lf2
$ mips-linux-gnu-readelf --dyn-syms f
$ ./f
1
1
$
Add attribute annotation to `f1' in f0.c for the other (local) case (in
which case 1 and 2 will be correctly printed).
I'll be providing suitably reduced assembly sources as test cases along
the upcoming fix.
References:
[1] "System V Application Binary Interface - DRAFT - 24 April 2001",
The Santa Cruz Operation, Inc., "Symbol Table",
--
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 ld/19908] MIPS/ELF: Hidden and internal dynamic symbols produced
https://sourceware.org/bugzilla/show_bug.cgi?id=19908 Maciej W. Rozycki changed: What|Removed |Added Status|NEW |ASSIGNED -- 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/19909] New: .d32 suffix is ignored for instructions with VEC_DISP8
https://sourceware.org/bugzilla/show_bug.cgi?id=19909 Bug ID: 19909 Summary: .d32 suffix is ignored for instructions with VEC_DISP8 Product: binutils Version: 2.27 (HEAD) Status: NEW Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: hjl.tools at gmail dot com Target Milestone: --- Target: x86 [hjl@gnu-tools-1 gas]$ cat /tmp/x.s vmovdqu64.d32 -0x40(%eax),%xmm3 [hjl@gnu-tools-1 gas]$ gcc -c /tmp/x.s [hjl@gnu-tools-1 gas]$ objdump -dwr x.o x.o: file format elf64-x86-64 Disassembly of section .text: <.text>: 0: 67 62 f1 fe 08 6f 58 fc vmovdqu64 -0x40(%eax),%xmm3 [hjl@gnu-tools-1 gas]$ -- 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/19498] Invalid "symbol definition loop encountered at `callmealias.lto_priv.1'" diagnostics for weakrefs
https://sourceware.org/bugzilla/show_bug.cgi?id=19498 --- Comment #6 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by H.J. Lu : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=df41fdf4bd2722ee610ecf31d92527aaad1fab76 commit df41fdf4bd2722ee610ecf31d92527aaad1fab76 Author: H.J. Lu Date: Mon Apr 4 20:45:30 2016 -0700 Add a testcase for PR gas/19498 PR gas/19498 * testsuite/gas/i386/i386.exp: Run pr19498. * testsuite/gas/i386/pr19498.d: New file. * testsuite/gas/i386/pr19498.s: Likewise. -- 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 ld/19827] Wrong relocation with defined symbol in PIE
https://sourceware.org/bugzilla/show_bug.cgi?id=19827 --- Comment #6 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by H.J. Lu : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=5fdf38727b4381d074dc929fd4b027a8779108fe commit 5fdf38727b4381d074dc929fd4b027a8779108fe Author: H.J. Lu Date: Mon Apr 4 20:50:19 2016 -0700 Add missing pr19827-nacl.rd for i386/x86-64 NaCl PR ld/19827 * testsuite/ld-i386/pr19827-nacl.rd: New file. * testsuite/ld-x86-64/pr19827-nacl.rd: Likewise. -- 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 ld/19827] Wrong relocation with defined symbol in PIE
https://sourceware.org/bugzilla/show_bug.cgi?id=19827 --- Comment #7 from cvs-commit at gcc dot gnu.org --- The binutils-2_26-branch branch has been updated by H.J. Lu : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=c3789ba84ab6df25a43ef533172202c32a98181d commit c3789ba84ab6df25a43ef533172202c32a98181d Author: H.J. Lu Date: Mon Apr 4 20:50:19 2016 -0700 Add missing pr19827-nacl.rd for i386/x86-64 NaCl Backport from master PR ld/19827 * testsuite/ld-i386/pr19827-nacl.rd: New file. * testsuite/ld-x86-64/pr19827-nacl.rd: Likewise. -- 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/19909] .d32 suffix is ignored for instructions with VEC_DISP8
https://sourceware.org/bugzilla/show_bug.cgi?id=19909 --- Comment #1 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by H.J. Lu : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=5be33403c378ceb9487ad14a1309392dc03a1263 commit 5be33403c378ceb9487ad14a1309392dc03a1263 Author: H.J. Lu Date: Mon Apr 4 21:19:27 2016 -0700 Don't use vec_disp8 encoding with the .d32 suffix Since the .d32 suffix prefers 32-bit displacement in encoding, try vec_disp8 encoding only if i.disp_encoding != disp_encoding_32bit. PR gas/19909 * config/tc-i386.c (check_VecOperands): Try vec_disp8 encoding only if i.disp_encoding != disp_encoding_32bit. * gas/testsuite/gas/i386/disp32.s: Add tests for vmovdqu64.d32. * gas/testsuite/gas/i386/x86-64-disp32.s: Likewise. * gas/testsuite/gas/i386/disp32.d: Updated. * gas/testsuite/gas/i386/x86-64-disp32.d: Likewise. -- 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
