BFD 2.16.1 "assertion failure" and "internal error"
Hello. I posted the details of this bug to the sourceware.org bugzilla but it did not appear that the report was replicated to this list (sorry if it was and this is a duplicate). For help with routing, the error messages I see are: BFD: BFD 2.16.1 assertion fail ../../binutils-2.16.1/bfd/coff-alpha.c:606 BFD: BFD 2.16.1 internal error, aborting at ../../binutils-2.16.1/bfd/coff-alpha.c line 635 in alpha_adjust_reloc_in The details of the bug are here: http://sourceware.org/bugzilla/show_bug.cgi?id=1030 Please contact me if you need some more information. Thanks. Dan ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
BFD bug with elf*-sparc sections?
NOTE:
I originally reported this in an email titled "BFD 2.16.1 'assertion
failure' and 'internal error'". I now believe that my original email
described two separate bugs, one with the DEC Alpha platform (that Nick
Clifton is investigating), and one with the Sparc platform.
A better description of the Sparc bug is below.
The BFD library is apparently not finding all the sections in a
elf*-sparc object file, produced with the SunPro C++ compiler.
It is also 'botching' the name of one of the sections.
To illustrate, compile this simple c++ file
#include
using namespace std;
void b()
{
cout << "b" << endl;
}
//EOF
with SunPro C++.
Running the native "elfdump -c" will show that there are 12 sections.
[output of elfdump -c:
http://www.cs.cornell.edu/marques/bfdexample/elfdump.txt ]
Running "objdump -h" (2.16 and 2.13) shows only 7 sections.
[output of objdump -h:
http://www.cs.cornell.edu/marques/bfdexample/objdump.txt ]
Notice that BFD is mishandling the name of one of the sections.
elfdump reports the following:
Section Header[3]: sh_name:
.group%__1cDstdEendl4Ccn0ALchar_traits4Cc___6Frn0ANbasic_ostream3CTACTB___4_
sh_addr: 0 sh_flags: 0
sh_size: 0xc sh_type:[ SHT_GROUP ]
sh_offset:0x1c8 sh_entsize: 0x4
sh_link: 10 sh_info:5
sh_addralign: 0x4
while objdump reports:
1
__1cDstdEendl4Ccn0ALchar_traits4Cc___6Frn0ANbasic_ostream3CTACTB___4_
0008 01c8 2**2
CONTENTS, READONLY, EXCLUDE, LINK_ONCE_DISCARD
As discussed in my original email, running objcopy on a c.o makes it
impossible to link the final application together.
To demonstrate, download
http://www.cs.cornell.edu/marques/bfdexample/a.cxx
http://www.cs.cornell.edu/marques/bfdexample/c.cxx
http://www.cs.cornell.edu/marques/bfdexample/Makefile
and run 'make final1' and 'make final2'.
Thanks.
Dan
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: BFD bug with elf*-sparc sections?
The output of readelf -h (2.16) looks correct to me: Yes it does. I wonder how it is implemented differently than objcopy and objdump... Anyway, the bug I am reporting is that using objcopy (even just to duplicate a .o file) is making SunPro C++ objects unlinkable. Using the source files and Makefile I posted to the web: http://www.cs.cornell.edu/marques/bfdexample/a.cxx http://www.cs.cornell.edu/marques/bfdexample/c.cxx http://www.cs.cornell.edu/marques/bfdexample/Makefile [EMAIL PROTECTED] objcopy_bug]$ gmake final1 Test without using objcopy CC -xarch=v8plusb -c a.cxx CC -xarch=v8plusb -c c.cxx CC -xarch=v8plusb a.o c.o -o final1 Test completed [EMAIL PROTECTED] objcopy_bug]$ gmake final2 Test with using objcopy CC -xarch=v8plusb -c a.cxx CC -xarch=v8plusb -c c.cxx objcopy a.o objcopy c.o CC -xarch=v8plusb a.o c.o -o final1 ld: fatal: symbol `std::basic_ostream<__type_0,__type_1>&std::endl >(std::basic_ostream<__type_0,__type_1>&)' is multiply-defined: (file a.o type=FUNC; file c.o type=FUNC); ld: fatal: File processing errors. No output written to final1 gmake: *** [final2] Error 1 Thanks. Dan ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: BFD bug with elf*-sparc sections?
My understanding is that objcopy has far less knowledge about the ELF format than readelf, and in particular about section group like item #3. May I ask you why you need to use Binutils with SunPro C++? AFAIK Sun doesn't implement the common C++ ABI. Maybe I'm confused as to the purpose of objcopy, and binutils in general. Is the purpose of binutils only to work with binaries created with the gnu tool chain? Or is it to work on any binaries created for a platform? I though that BFD (and I assumed by extension, binutils) was "a library which provides a single interface to read and write object files, executables, archive files, and core files in any format." If the purpose is to work with general binaries, it seems that 'dropping' the section group stuff is clearly a bug. Particularly, I want to use objcopy for its redefine-sym function, e.g., I want certain .o files to call xxx_malloc instead of malloc, but not redefine malloc everywhere. As I want to be able to do this on different platform, I though that I would use binutils, rather than develop a platform specific solution everywhere. I had no problems with C, but moving to C++ has been a pain. Dan ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: BFD bug with elf*-sparc sections?
I do not have access to the SUNPro C++ compiler, so would it be possible for you to make the .o files available as well please ? The .o files produced by the SunPro C++ compiler are posted: http://www.cs.cornell.edu/marques/bfdexample/a.o http://www.cs.cornell.edu/marques/bfdexample/c.o I also posted the results of using GNU objcopy (2.16) to copy those files: http://www.cs.cornell.edu/marques/bfdexample/a.copied.o http://www.cs.cornell.edu/marques/bfdexample/c.copied.o Thanks. Dan ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: BFD 2.16.1 "assertion failure" and "internal error"
Ah - right. Yes it looks for magic bytes. Have a look at the function alpha_ecoff_object_p() in bfd/coff-alpha.c. This is the function that is supposed to determine if an object file is an ALPHA object file in COFF format. OK, some progress to report here... The standard ALPHA_MAGIC number is 0x183. However, the DEC C and C++ compilers can generate compressed binary files, whose magic number will be 0x188. These will be generated if the compiler (or assembler) is passed the "-compress" option. To confuse matters, for C, that flag is NOT passed by default but for C++ it is. Unfortunately, BFD cannot handle 0x188. To generate 0x183, "-nocompress" must be explicitly passed to the C++ compiler. An alternative would be to use the 'objZ -u' command to uncompress the .o file. Presumably, this could be done automatically from within the BFD library. This was a bit confusing to figure out, as the native "odump -f" would report the same magic number (0x183) for each. I assume that this was because it did the decompression automatically. In another email I claimed objcopy "does recognize those binaries if they have been modified by the linker". This is because, again, the linker automatically did the decompression. Anyway, the native "/bin/file" tool was helpful: bash-2.04$ cxx -c test.cxx bash-2.04$ file test.o test.o: alpha compressed COFF executable or object module not stripped - version 3.13-6 bash-2.04$ cxx -c -nocompress test.cxx bash-2.04$ file test.o test.o: COFF format alpha executable or object module not stripped - version 3.13-6 Dan ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: BFD 2.16.1 "assertion failure" and "internal error"
I think that the simplest change we could make would be to have BFD
detect object files with a magic number of 0x188 and then have it issue
an error message along the lines of "please decompress this file before
passing it to BFD". What do you think ?
Nick,
This makes sense, so I've attached a patch that does just this.
Let me know when/if you incorporate it to the cvs tree, and when the
patch that you proposed makes it in.
:) Then we can focus on the Sparc stuff :)
Thanks for all your help.
Dan
diff -r -c binutils-2.16.1-orig/bfd/coff-alpha.c
binutils-2.16.1/bfd/coff-alpha.c
*** binutils-2.16.1-orig/bfd/coff-alpha.c Wed Jul 13 14:42:11 2005
--- binutils-2.16.1/bfd/coff-alpha.cWed Jul 13 14:54:38 2005
***
*** 482,488
struct internal_filehdr *internal_f = (struct internal_filehdr *) filehdr;
if (ALPHA_ECOFF_BADMAG (*internal_f))
! return FALSE;
return TRUE;
}
--- 482,497
struct internal_filehdr *internal_f = (struct internal_filehdr *) filehdr;
if (ALPHA_ECOFF_BADMAG (*internal_f))
! {
! if (ALPHA_ECOFF_COMPRESSEDMAG (*internal_f))
! {
! (*_bfd_error_handler)
! (_("%B: Cannot handle compressed Alpha binaries.\n"
! " Use compiler flags, or objZ, to generate uncompressed
binaries."),
!abfd);
! }
! return FALSE;
! }
return TRUE;
}
diff -r -c binutils-2.16.1-orig/include/coff/alpha.h
binutils-2.16.1/include/coff/alpha.h
*** binutils-2.16.1-orig/include/coff/alpha.h Wed Jul 13 14:42:48 2005
--- binutils-2.16.1/include/coff/alpha.hWed Jul 13 14:45:12 2005
***
*** 34,39
--- 34,45
#define ALPHA_ECOFF_BADMAG(x) \
((x).f_magic != ALPHA_MAGIC && (x).f_magic != ALPHA_MAGIC_BSD)
+ #define ALPHA_ECOFF_COMPRESSEDMAG(x) \
+ ((x).f_magic == ALPHA_MAGIC_COMPRESSED )
+
+
+
+
/* The object type is encoded in the f_flags. */
#define F_ALPHA_OBJECT_TYPE_MASK 0x3000
#define F_ALPHA_NO_SHARED 0x1000
diff -r -c binutils-2.16.1-orig/include/coff/ecoff.h
binutils-2.16.1/include/coff/ecoff.h
*** binutils-2.16.1-orig/include/coff/ecoff.h Wed Jul 13 14:42:48 2005
--- binutils-2.16.1/include/coff/ecoff.hWed Jul 13 14:44:24 2005
***
*** 40,45
--- 40,46
/* Alpha magic numbers used in filehdr. */
#define ALPHA_MAGIC 0x183
+ #define ALPHA_MAGIC_COMPRESSED 0x188
#define ALPHA_MAGIC_BSD 0x185
/* Magic numbers used in a.out header. */
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
