[Bug ld/4277] BFD reports internal error at elflink.c in elf_link_output_extsym
--- Additional Comments From hjl at lucon dot org 2007-03-29 14:50 ---
I guess
LDFLAGS=-s
-Wl,-O1,-zdynsort,-z,combreloc,-hashval,--as-needed,--enable-new-dtags -Bdirect
doesn't work with your linker. I have no problems on FC6:
bash-3.1$ cat x.c
#include
int
main ()
{
printf ("Hello\n");
}
bash-3.1$ gcc -B/usr/bin/ -v -O4 -march=k8 -mtune=k8 -pipe -s -ftree-vectorize
-s -Wl,-O1,-zdynsort,-z,combreloc,-hashval,--as-needed,--enable-new-dtags
-Bdirect x.c
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic
--host=x86_64-redhat-linux
Thread model: posix
gcc version 4.1.1 20070105 (Red Hat 4.1.1-51)
/usr/libexec/gcc/x86_64-redhat-linux/4.1.1/cc1 -quiet -v x.c -quiet -dumpbase
x.c -march=k8 -mtune=k8 -auxbase x -O4 -version -ftree-vectorize -o - |
/usr/bin/as -V -Qy -o /tmp/cciagvla.o -
GNU assembler version 2.17.50.0.6-2.fc6 (x86_64-redhat-linux) using BFD version
2.17.50.0.6-2.fc6 20061020
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/4.1.1/../../../../x86_64-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/lib/gcc/x86_64-redhat-linux/4.1.1/include
/usr/include
End of search list.
GNU C version 4.1.1 20070105 (Red Hat 4.1.1-51) (x86_64-redhat-linux)
compiled by GNU C version 4.1.1 20070105 (Red Hat 4.1.1-51).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: d39c53922a350f9879c557cb2a22eafa
/usr/libexec/gcc/x86_64-redhat-linux/4.1.1/collect2 --eh-frame-hdr -m
elf_x86_64 --hash-style=gnu -dynamic-linker /lib64/ld-linux-x86-64.so.2 -s -s
/usr/lib/gcc/x86_64-redhat-linux/4.1.1/../../../../lib64/crt1.o
/usr/lib/gcc/x86_64-redhat-linux/4.1.1/../../../../lib64/crti.o
/usr/lib/gcc/x86_64-redhat-linux/4.1.1/crtbegin.o -L/usr/bin
-L/usr/lib/gcc/x86_64-redhat-linux/4.1.1
-L/usr/lib/gcc/x86_64-redhat-linux/4.1.1
-L/usr/lib/gcc/x86_64-redhat-linux/4.1.1/../../../../lib64 -L/lib/../lib64
-L/usr/lib/../lib64 -O1 -zdynsort -z combreloc -hashval --as-needed
--enable-new-dtags /tmp/cciagvla.o -lgcc --as-needed -lgcc_s --no-as-needed -lc
-lgcc --as-needed -lgcc_s --no-as-needed
/usr/lib/gcc/x86_64-redhat-linux/4.1.1/crtend.o
/usr/lib/gcc/x86_64-redhat-linux/4.1.1/../../../../lib64/crtn.o
bash-3.1$ ./a.out
Hello
bash-3.1$
--
What|Removed |Added
CC||hjl at lucon dot org
Status|NEW |RESOLVED
Resolution||WORKSFORME
Version|2.17|2.18 (HEAD)
http://sourceware.org/bugzilla/show_bug.cgi?id=4277
--- 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
Re: [Bug binutils/4110] Broken object file crashes nm
Hi Sami,
Right, first of all, I have checked in the patch as it currently
exists (patch.5). We will be branching for release 2.18 at some point
in the near future and I want to make sure that the error checking we
have already developed gets into that release. I added this ChangeLog
entry:
bfd/ChangeLog
PR binutils/4110
* elf.c (IS_VALID_GROUP_SECTION_HEADER): New macro.
(setup_group): Use it. Report corrupt group section headers.
(bfd_section_from_shdr): Use new macro. Replace constant 4 with
GRP_ENTRY_SIZE. Cope with NULLs in the group section table.
(elf_fake_section): Replace constant 4 with GRP_ENTRY_SIZE.
Sorry for taking some time to reply. It seems I can't reproduce the SEGV
anymore myself (don't know what changed), but I do get a valgrind error. And I
also have a log of nm crashing twice on that input file. By the way now that I
test I also get the same Valgrind error with broken3.o and broken4.o. It seems
the uninitialized variable has to be still idx->shdr as probably was the case
with broken4.o, however I can't get that either to crash any more.
==15602== Conditional jump or move depends on uninitialised value(s)
==15602==at 0x433A71: bfd_section_from_shdr (elf.c:2181)
(gdb) print idx
$1 = (Elf_Internal_Group *) 0x4d5c9f0
(gdb) print *idx
$2 = {shdr = 0x0, flags = 0}
(gdb) l
2176 idx += n_elt;
2177 while (--n_elt != 0)
2178{
2179 --idx;
2180
2181 if (idx->shdr != NULL
2182 && (s = idx->shdr->bfd_section) != NULL
2183 && elf_next_in_group (s) != NULL)
2184{
2185 elf_next_in_group (hdr->bfd_section) = s;
Hmm, I do not see how the idx->shdr array can be uninitialized... I did
find another place in elf.c where we assume that the group section
contents will always be valid pointers, hence I am uploading another
patch to fix that. But I doubt if that will resolve the valgrind issue.
I think that we need a seg-faulting test case before we can proceed
any further.
(Just as a guess, do you get a seg fault if you run any of the tests
with the environment variable MALLOC_CHECK_ set to 2 ? I tried, but
they all ran OK).
Cheers
Nick
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/4110] Broken object file crashes nm
--- Additional Comments From nickc at redhat dot com 2007-03-29 16:01
---
Subject: Re: Broken object file crashes nm
Hi Sami,
Right, first of all, I have checked in the patch as it currently
exists (patch.5). We will be branching for release 2.18 at some point
in the near future and I want to make sure that the error checking we
have already developed gets into that release. I added this ChangeLog
entry:
bfd/ChangeLog
PR binutils/4110
* elf.c (IS_VALID_GROUP_SECTION_HEADER): New macro.
(setup_group): Use it. Report corrupt group section headers.
(bfd_section_from_shdr): Use new macro. Replace constant 4 with
GRP_ENTRY_SIZE. Cope with NULLs in the group section table.
(elf_fake_section): Replace constant 4 with GRP_ENTRY_SIZE.
> Sorry for taking some time to reply. It seems I can't reproduce the SEGV
> anymore myself (don't know what changed), but I do get a valgrind error. And
> I
> also have a log of nm crashing twice on that input file. By the way now that
> I
> test I also get the same Valgrind error with broken3.o and broken4.o. It
> seems
> the uninitialized variable has to be still idx->shdr as probably was the case
> with broken4.o, however I can't get that either to crash any more.
> ==15602== Conditional jump or move depends on uninitialised value(s)
> ==15602==at 0x433A71: bfd_section_from_shdr (elf.c:2181)
> (gdb) print idx
> $1 = (Elf_Internal_Group *) 0x4d5c9f0
> (gdb) print *idx
> $2 = {shdr = 0x0, flags = 0}
> (gdb) l
> 2176 idx += n_elt;
> 2177 while (--n_elt != 0)
> 2178{
> 2179 --idx;
> 2180
> 2181 if (idx->shdr != NULL
> 2182 && (s = idx->shdr->bfd_section) != NULL
> 2183 && elf_next_in_group (s) != NULL)
> 2184{
> 2185 elf_next_in_group (hdr->bfd_section) = s;
Hmm, I do not see how the idx->shdr array can be uninitialized... I did
find another place in elf.c where we assume that the group section
contents will always be valid pointers, hence I am uploading another
patch to fix that. But I doubt if that will resolve the valgrind issue.
I think that we need a seg-faulting test case before we can proceed
any further.
(Just as a guess, do you get a seg fault if you run any of the tests
with the environment variable MALLOC_CHECK_ set to 2 ? I tried, but
they all ran OK).
Cheers
Nick
--
http://sourceware.org/bugzilla/show_bug.cgi?id=4110
--- 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 binutils/4110] Broken object file crashes nm
--- Additional Comments From nickc at redhat dot com 2007-03-29 16:01 --- Created an attachment (id=1655) --> (http://sourceware.org/bugzilla/attachment.cgi?id=1655&action=view) Add another check for a NULL idx->shdr entry. -- http://sourceware.org/bugzilla/show_bug.cgi?id=4110 --- 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 binutils/4292] nm and objdump show addresses on 64 bits for 32bit a.out files
--- Additional Comments From hjl at lucon dot org 2007-03-29 17:04 --- It works for me. Please provide a QMAGIC file which shows the problem. -- What|Removed |Added CC||hjl at lucon dot org http://sourceware.org/bugzilla/show_bug.cgi?id=4292 --- 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 binutils/4292] nm and objdump show addresses on 64 bits for 32bit a.out files
--- Additional Comments From Quentin dot Godfroy at ens dot fr 2007-03-29 17:17 --- Created an attachment (id=1656) --> (http://sourceware.org/bugzilla/attachment.cgi?id=1656&action=view) QMAGIC sample This sample was created with as and ld configured with host=x86_64-linux and target=i486-linuxaout. % file /opt/binutils-2.17-aout/i386-linuxaout/bin/nm /opt/binutils-2.17-aout/i386-linuxaout/bin/nm: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.0, dynamically linked (uses shared libs), for GNU/Linux 2.6.0, stripped % /opt/binutils-2.17-aout/i386-linuxaout/bin/nm affiche 1020 t affiche.o 2010 A __bss_start 2010 D _edata 2010 D __edata 2010 A _end 2010 A __end 1058 T _etext 1058 T __etext 102a t .L0 1037 t .L1 2000 d output 1020 T _start -- http://sourceware.org/bugzilla/show_bug.cgi?id=4292 --- 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 binutils/4292] nm and objdump show addresses on 64 bits for 32bit a.out files
--- Additional Comments From hjl at lucon dot org 2007-03-29 17:35 --- That is normal since bfd_vma is 64bit on 64bit host. The same applies to any 32bit targets, including ELF/i386. -- http://sourceware.org/bugzilla/show_bug.cgi?id=4292 --- 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 binutils/4292] nm and objdump show addresses on 64 bits for 32bit a.out files
--- Additional Comments From nickc at redhat dot com 2007-03-29 17:41 --- Created an attachment (id=1657) --> (http://sourceware.org/bugzilla/attachment.cgi?id=1657&action=view) Make nm print addresses of symbols as 32-bit or 64-bit values, depending upon the size of the target -- http://sourceware.org/bugzilla/show_bug.cgi?id=4292 --- 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 binutils/4292] nm and objdump show addresses on 64 bits for 32bit a.out files
--- Additional Comments From hjl at lucon dot org 2007-03-29 18:16 --- It is not just nm. Almost all programs in binutils behave the same when displaying address, either for output or error message. We should be very careful, not to hide problems. For example, when nm shows ... for 32bit file on 64bit host. We'd like to know the high 32bits since they may indicate problems in binutils itself. -- http://sourceware.org/bugzilla/show_bug.cgi?id=4292 --- 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 binutils/4292] nm and objdump show addresses on 64 bits for 32bit a.out files
--- Additional Comments From nickc at redhat dot com 2007-03-29 18:16 --- Created an attachment (id=1658) --> (http://sourceware.org/bugzilla/attachment.cgi?id=1658&action=view) Improved version of previous patch with better heuristics for guessing target address size -- What|Removed |Added Attachment #1657 is|0 |1 obsolete|| http://sourceware.org/bugzilla/show_bug.cgi?id=4292 --- 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
Re: [Bug binutils/4292] nm and objdump show addresses on 64 bits for 32bit a.out files
Hi Quentin, target=i486-linuxaout. The problem here is that the aout file format does not specify the address size of the objects it contains, so the BFD library does not know whether the objects are 32-bit or 64-bit. Instead nm defaults to using the bitsize of the host. I have uploaded a patch which improves nm's heuristic. Now if the BFD library cannot tell it the bitsize of the target it will look at the target format's name. If the string "64" occurs anywhere in the name then it will assume a 64-bit bitsize, otherwise it will assume a 32-bit bitsize. Not perfect but I think that it should work most of the time. Please try out the patch and let me know what you think. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/4292] nm and objdump show addresses on 64 bits for 32bit a.out files
--- Additional Comments From nickc at redhat dot com 2007-03-29 18:17 --- Subject: Re: nm and objdump show addresses on 64 bits for32bit a.out files Hi Quentin, > target=i486-linuxaout. The problem here is that the aout file format does not specify the address size of the objects it contains, so the BFD library does not know whether the objects are 32-bit or 64-bit. Instead nm defaults to using the bitsize of the host. I have uploaded a patch which improves nm's heuristic. Now if the BFD library cannot tell it the bitsize of the target it will look at the target format's name. If the string "64" occurs anywhere in the name then it will assume a 64-bit bitsize, otherwise it will assume a 32-bit bitsize. Not perfect but I think that it should work most of the time. Please try out the patch and let me know what you think. Cheers Nick -- http://sourceware.org/bugzilla/show_bug.cgi?id=4292 --- 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 binutils/4292] nm and objdump show addresses on 64 bits for 32bit a.out files
--- Additional Comments From Quentin dot Godfroy at ens dot fr 2007-03-29 19:35 --- (In reply to comment #7) > Subject: Re: nm and objdump show addresses on 64 bits > for 32bit a.out files > > > target=i486-linuxaout. > > The problem here is that the aout file format does not specify the > address size of the objects it contains, so the BFD library does not > know whether the objects are 32-bit or 64-bit. Instead nm defaults to > using the bitsize of the host. Or the maximum bitsize of its targets, as the problem also shows for 32bit tools but who can handle 64bit objects. > Please try out the patch and let me know what you think. It works, thanks (I suppose the work could also be done on objdump, to have a coherent behaviour), but it breaks the purpouse H.J. Lu mentioned. It's indeed not clear about what should be done, for multi-arch utils. Maybe a switch ? (but it would become much more than a small patch, and I don't want to have an argument with developpers) -- http://sourceware.org/bugzilla/show_bug.cgi?id=4292 --- 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
