[Bug gold/12771] New: internal error in value_from_output_section, at ../../gold/reloc.cc:1508 on armel
http://sourceware.org/bugzilla/show_bug.cgi?id=12771 Summary: internal error in value_from_output_section, at ../../gold/reloc.cc:1508 on armel Product: binutils Version: 2.22 (HEAD) Status: NEW Severity: normal Priority: P2 Component: gold AssignedTo: i...@airs.com ReportedBy: jrnie...@gmail.com CC: timo.lindf...@iki.fi Created attachment 5730 -- http://sourceware.org/bugzilla/attachment.cgi?id=5730 testcase Hi, Timo Lindfors found that running ld.gold allcodecs.o with this object file on his sheevaplug produces ld.gold: internal error in value_from_output_section, at ../../gold/reloc.cc:1508 and an exit status of 1. It's reproducible with real hardware but not with qemu (on qemu one instead gets the expected bunch of error: undefined reference errors for objects not passed on the command line). Tests so far have been with 2.21.51.20110421-4 from Debian sid but presumably it shouldn't be hard to check with the latest from git://sources.redhat.com/git/binutils.git if that's useful. http://bugs.debian.org/616715 has details. Any hints for tracking this down? Thanks for gold :) Jonathan -- 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
gas-2.20.90.pot errors
Hi, I found the following typos in the gas-2.20.90.pot file: #: cond.c:314 #: cond.c:420 msgid here is the previous \else\ Should it be .else here, not else ? #: cond.c:317 #: cond.c:423 msgid here is the previous \if\ Shoud it be .if here, not if ? #: cond.c:417 msgid duplicate \else\ Should it be .else here, not else ? #: config/tc-arm.c:2401 #, c-format msgid ignoring attempt to undefine built-in register '%s' I do not understand this one. Should it be redefine, not undefine ? #: config/tc-ia64.c:6989 msgid IA-64 options:\n --mconstant-gp\t mark output file as using the constant-GP model\n \t\t\t (sets ELF header flag EF_IA_64_CONS_GP)\n --mauto-pic\t\t mark output file as using the constant-GP model\n \t\t\t without function descriptors (sets ELF header flag\n \t\t\t EF_IA_64_NOFUNCDESC_CONS_GP)\n -milp32|-milp64|-mlp64|-mp64\tselect data model (default -mlp64)\n -mle | -mbe\t\t select little- or big-endian byte order (default -mle)\n -mtune=[itanium1|itanium2]\n \t\t\t tune for a specific CPU (default -mtune=itanium2)\n -munwind-check=[warning|error]\n \t\t\t unwind directive check (default -munwind-check=warning)\n -mhint.b=[ok|warning|error]\n \t\t\t hint.b check (default -mhint.b=error)\n -x | -xexplicit\t turn on dependency violation checking\n -xauto\t\t automagically remove dependency violations (default)\n -xnone\t\t turn off dependency violation checking\n -xdebug\t\t debug dependency violation checker\n -xdebugn\t\t debug dependency violation checker but turn off\n \t\t\t dependency violation checking\n -xdebugx\t\t debug dependency violation checker and turn on\n \t\t\t dependency violation checking\n Should it be automatically here, not automagically (in -xauto) ? #: config/tc-m32r.c:408 #, c-format msgid fo contraint violations\n Should it be for constraint here, not fo contraint ? #: config/tc-m32r.c:412 #, c-format msgid contraint violations\n Here too constraint ? #: config/tc-mt.c:261 #, c-format msgid operand references R%ld of previous instrutcion. Should it be instruction here, not instrutcion ? #: config/tc-mt.c:267 #, c-format msgid operand references R%ld of instructcion before previous. Here too. #: config/tc-pj.c:289 msgid expected expresssion Should it be expression here, not expresssion ? #: config/tc-v850.c:1279 msgid second register should greater tahn first register Should it be than here, not tahn ? Best regards, Jorma Karvonen ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/12762] lto produces multiple definition errors for all symbols (including CRT) in C++
http://sourceware.org/bugzilla/show_bug.cgi?id=12762 vanboxem.ruben at gmail dot com changed: What|Removed |Added Summary|lto produces multiple |lto produces multiple |definition errors for |definition errors for all |virtual function|symbols (including CRT) in ||C++ -- 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 ld/12760] LTO doesn't work with .gnu.warning section
http://sourceware.org/bugzilla/show_bug.cgi?id=12760 --- Comment #9 from cvs-commit at gcc dot gnu.org cvs-commit at gcc dot gnu.org 2011-05-17 13:02:22 UTC --- CVSROOT:/cvs/src Module name:src Changes by:amo...@sourceware.org2011-05-17 13:02:18 Modified files: include: ChangeLog bfdlink.h bfd: ChangeLog coff-aux.c elflink.c linker.c ld : ChangeLog ldmain.c plugin.c Log message: PR ld/12760 include/ * bfdlink.h (struct bfd_link_callbacks notice): Add flags and string param. bfd/ * coff-aux.c (coff_m68k_aux_link_add_one_symbol): Adjust notice call. * elflink.c (elf_link_add_object_symbols): Likewise. * linker.c (_bfd_generic_link_add_one_symbol): Likewise. ld/ * ldmain.c (notice): Add flags and string param. * plugin.c (plugin_notice): Likewise. Handle indirect, warning and constructor syms. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/include/ChangeLog.diff?cvsroot=srcr1=1.532r2=1.533 http://sourceware.org/cgi-bin/cvsweb.cgi/src/include/bfdlink.h.diff?cvsroot=srcr1=1.86r2=1.87 http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/ChangeLog.diff?cvsroot=srcr1=1.5344r2=1.5345 http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/coff-aux.c.diff?cvsroot=srcr1=1.11r2=1.12 http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/elflink.c.diff?cvsroot=srcr1=1.403r2=1.404 http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/linker.c.diff?cvsroot=srcr1=1.82r2=1.83 http://sourceware.org/cgi-bin/cvsweb.cgi/src/ld/ChangeLog.diff?cvsroot=srcr1=1.2334r2=1.2335 http://sourceware.org/cgi-bin/cvsweb.cgi/src/ld/ldmain.c.diff?cvsroot=srcr1=1.154r2=1.155 http://sourceware.org/cgi-bin/cvsweb.cgi/src/ld/plugin.c.diff?cvsroot=srcr1=1.34r2=1.35 -- 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 ld/12772] New: relocations from discarded sections stay
http://sourceware.org/bugzilla/show_bug.cgi?id=12772
Summary: relocations from discarded sections stay
Product: binutils
Version: 2.22 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: ld
AssignedTo: unassig...@sources.redhat.com
ReportedBy: m...@suse.de
(this got initially reported into Novell bugzilla #694266).
Compile this with the following compile command on x86_64-linux:
# g++ -O3 -Wl,-gc-sections -fpic -shared \
-fdata-sections -ffunction-sections \
-fvisibility-inlines-hidden -fvisibility=hidden \
-o test.so test.cpp
# cat test.cpp
#include string.h
#include stdlib.h
#include unistd.h
extern C int __attribute__((visibility(default))) func(char *ptr)
{
static const char g_const[] = { 1, 1, 0 };
memcpy(ptr, g_const, 3);
return 0;
}
extern C char *func2(char *ptr)
{
static char buf[4096];
if (!getcwd(buf, sizeof(buf)))
buf[0] = 0;
#define STR test_string
memcpy(ptr, STR, sizeof(STR));
return buf;
}
Note that func2 will be hidden, and as it's unreferenced the .text.func2
section will be discarded, as will be the .bss._ZZ5func2E3buf section:
# ...
./ld/ld-new: Removing unused section '.text.func2' in file
'show-link-discard-fail.o'
./ld/ld-new: Removing unused section '.bss._ZZ5func2E3buf' in file
'show-link-discard-fail.o'
But the relocation to getcwd (or better it's default decorated variant
getcwd@@GLIBC_2.2.5) will stay and transferred into the output file.
It should have been discarded too. In fact the gc_sweep_hook on x86_64
for instance does lower the PLT count for this reloc, and hence seems
to assume that it really won't be emitted. But alas, it is.
--
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 ld/12762] lto produces multiple definition errors for all symbols (including CRT) in C++
http://sourceware.org/bugzilla/show_bug.cgi?id=12762 vanboxem.ruben at gmail dot com changed: What|Removed |Added CC||ktietz70 at googlemail dot ||com --- Comment #6 from vanboxem.ruben at gmail dot com 2011-05-17 13:27:46 UTC --- When compiling libstdc++ with -flto in CFLAGS, libstdc++'s config.log shows a failed test with these errors (along with the previous multiple definition errors): `__multf3' referenced in section `.text' of /tmp/ccbxHWuQ.ltrans0.ltrans.o: defined in discarded section `.text' of multf3.o (symbol from plugin) `__multf3' referenced in section `.text' of /tmp/ccbxHWuQ.ltrans0.ltrans.o: defined in discarded section `.text' of multf3.o (symbol from plugin) `__multf3' referenced in section `.text' of /tmp/ccbxHWuQ.ltrans0.ltrans.o: defined in discarded section `.text' of multf3.o (symbol from plugin) `__multf3' referenced in section `.text' of /tmp/ccbxHWuQ.ltrans0.ltrans.o: defined in discarded section `.text' of multf3.o (symbol from plugin) `__subtf3' referenced in section `.text' of /tmp/ccbxHWuQ.ltrans0.ltrans.o: defined in discarded section `.text' of subtf3.o (symbol from plugin) `__addtf3' referenced in section `.text' of /tmp/ccbxHWuQ.ltrans0.ltrans.o: defined in discarded section `.text' of addtf3.o (symbol from plugin) `__subtf3' referenced in section `.text' of /tmp/ccbxHWuQ.ltrans0.ltrans.o: defined in discarded section `.text' of subtf3.o (symbol from plugin) ... In total it seems ld is reading all symbols multiple times in the same object file, and -- 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 ld/12759] rx-elf-ld needs --no-ignore-lma
http://sourceware.org/bugzilla/show_bug.cgi?id=12759 --- Comment #2 from cvs-commit at gcc dot gnu.org cvs-commit at gcc dot gnu.org 2011-05-17 16:02:35 UTC --- CVSROOT:/cvs/src Module name:src Changes by:ni...@sourceware.org2011-05-17 16:02:31 Modified files: ld : ChangeLog ld/emultempl : rxelf.em bfd: ChangeLog elf32-rx.c Log message: PR ld/12759 * emultempl/rxelf.em (ignore_lma): New variable. (rx_elf_create_output_section_statements): Pass the setiing of ignore_lma to bfd_elf32_rx_set_target_flags. (OPTION_IGNORE_LMA): Define. (OPTION_NO_IGNORE_LMA): Define. (PARSE_AND_LIST_LONGOPTS): Add ignore lma. (PARSE_AND_LIST_OPTIONS): Add ignore lma. (PARSE_AND_LIST_ARGS_CASES): Add ignore lma. * elf32-rx.c (ignore_lma): New variable. (bfd_elf32_rx_set_target_flags): Add ignore_lma parameter. (rx_modify_program_headers): Only copy the LMA into the VMA if ignore_lma is true. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/ld/ChangeLog.diff?cvsroot=srcr1=1.2335r2=1.2336 http://sourceware.org/cgi-bin/cvsweb.cgi/src/ld/emultempl/rxelf.em.diff?cvsroot=srcr1=1.1r2=1.2 http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/ChangeLog.diff?cvsroot=srcr1=1.5345r2=1.5346 http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/elf32-rx.c.diff?cvsroot=srcr1=1.9r2=1.10 -- 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 ld/12759] rx-elf-ld needs --no-ignore-lma
http://sourceware.org/bugzilla/show_bug.cgi?id=12759 Nick Clifton nickc at redhat dot com changed: What|Removed |Added Status|NEW |RESOLVED CC||nickc at redhat dot com Resolution||FIXED --- Comment #3 from Nick Clifton nickc at redhat dot com 2011-05-17 16:05:00 UTC --- Hi Tomohiro-san, Thanks for submitting this patch. I have checked it in along with these changelog entries. Cheers Nick bfd/ChangeLog 2011-05-17 Tomohiro Kashiwada kikair...@gmail.com PR ld/12759 * elf32-rx.c (ignore_lma): New variable. (bfd_elf32_rx_set_target_flags): Add ignore_lma parameter. (rx_modify_program_headers): Only copy the LMA into the VMA if ignore_lma is true. ld/ChangeLog 2011-05-17 Tomohiro Kashiwada kikair...@gmail.com PR ld/12759 * emultempl/rxelf.em (ignore_lma): New variable. (rx_elf_create_output_section_statements): Pass the setiing of ignore_lma to bfd_elf32_rx_set_target_flags. (OPTION_IGNORE_LMA): Define. (OPTION_NO_IGNORE_LMA): Define. (PARSE_AND_LIST_LONGOPTS): Add ignore lma. (PARSE_AND_LIST_OPTIONS): Add ignore lma. (PARSE_AND_LIST_ARGS_CASES): Add ignore lma. -- 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: gas-2.20.90.pot errors
Hi Jorma, I have checked in a patch to fix the typos that you reported. There were a couple of other questions though: #: config/tc-arm.c:2401 #, c-format msgid ignoring attempt to undefine built-in register '%s' I do not understand this one. Should it be redefine, not undefine ? Actually no, undefine is correct. The message occurs when the user has something like this in their assembler source code: .unreq r1 The .unreq pseudo-op is used to remove a register name alias that was created by an earlier .req pseudo-op. But if the user tries to use it to undefine one of the standard register names then they receive the warning message shown above. Here is an example of the correct operation of the .unreq pseudo-op: arg1 .req r4 arg2 .req r5 foo: add arg2, arg1 rts .unreq arg1 .unreq arg2 So arg1 and arg are aliases for registers 4 and 5, and they are being used to make the code more readable. But they are undefined at the end of the definition of function foo, so that they will not affect code later on in the source file. Perhaps a more understandable warning message would be: ignoring attempt to use .unreq on a fixed register name What do you think ? #: config/tc-ia64.c:6989 [...] -xauto\t\t automagically remove dependency violations (default)\n [...] Should it be automatically here, not automagically (in -xauto) ? Yes and no. Automagically is one of those computer geek puns. It means automatically and in a somewhat magical way. It implies that not only will the feature happen without any user intervention, but also that it will do what the user wants without them even understanding how it works. When translating, treating automagically as if it were automatically is perfectly acceptable. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
Re: gas-2.20.90.pot errors
2011/5/17, Nick Clifton ni...@redhat.com: I do not understand this one. Should it be redefine, not undefine ? Actually no, undefine is correct. The message occurs when the user has something like this in their assembler source code: .unreq r1 The .unreq pseudo-op is used to remove a register name alias that was created by an earlier .req pseudo-op. But if the user tries to use it to undefine one of the standard register names then they receive the warning message shown above. Here is an example of the correct operation of the .unreq pseudo-op: arg1 .req r4 arg2 .req r5 foo: add arg2, arg1 rts .unreq arg1 .unreq arg2 So arg1 and arg are aliases for registers 4 and 5, and they are being used to make the code more readable. But they are undefined at the end of the definition of function foo, so that they will not affect code later on in the source file. Perhaps a more understandable warning message would be: ignoring attempt to use .unreq on a fixed register name What do you think ? Yes, that is right. PLS, could you add this explanation as a comment to the source code so that is shown in .pot file for the translators. #: config/tc-ia64.c:6989 [...] -xauto\t\t automagically remove dependency violations (default)\n [...] Should it be automatically here, not automagically (in -xauto) ? Yes and no. Automagically is one of those computer geek puns. It means automatically and in a somewhat magical way. It implies that not only will the feature happen without any user intervention, but also that it will do what the user wants without them even understanding how it works. When translating, treating automagically as if it were automatically is perfectly acceptable. OK, here could some comment for translators be nice. PLS, you could also add a patch for Finnish translation of gas: http://translationproject.org/PO-files/fi/gas-2.20.90.fi.po Br, Jorma K. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/12772] relocations from discarded sections stay
http://sourceware.org/bugzilla/show_bug.cgi?id=12772
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2011-05-17 21:21:11
UTC ---
Works for me:
[hjl@gnu-6 pr12772]$ cat x.cc
#include string.h
#include stdlib.h
#include unistd.h
extern C int __attribute__((visibility(default))) func(char *ptr)
{
static const char g_const[] = { 1, 1, 0 };
memcpy(ptr, g_const, 3);
return 0;
}
extern C char *func2(char *ptr)
{
static char buf[4096];
if (!getcwd(buf, sizeof(buf)))
buf[0] = 0;
#define STR test_string
memcpy(ptr, STR, sizeof(STR));
return buf;
}
[hjl@gnu-6 pr12772]$ make
g++ -c -fpic -O3 -fdata-sections -ffunction-sections
-fvisibility-inlines-hidden -fvisibility=hidden -o x.o x.cc
g++ -shared -Wl,-gc-sections -o x.so x.o
readelf -r x.so
Relocation section '.rela.dyn' at offset 0x3f0 contains 4 entries:
Offset Info Type Sym. ValueSym. Name +
Addend
00200640 0008 R_X86_64_RELATIVE
00200640
002007f8 00020006 R_X86_64_GLOB_DAT __gmon_start__ +
0
00200800 00030006 R_X86_64_GLOB_DAT
_Jv_RegisterClasses + 0
00200808 00040006 R_X86_64_GLOB_DAT __cxa_finalize +
0
Relocation section '.rela.plt' at offset 0x450 contains 1 entries:
Offset Info Type Sym. ValueSym. Name +
Addend
00200828 00040007 R_X86_64_JUMP_SLO __cxa_finalize +
0
[hjl@gnu-6 pr12772]$
--
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 ld/12772] relocations from discarded sections stay
http://sourceware.org/bugzilla/show_bug.cgi?id=12772 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||hjl.tools at gmail dot com -- 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
