Re: BFD bug with elf*-sparc sections?
> 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 ] The output of readelf -h (2.16) looks correct to me: Section Headers: [Nr] Name TypeAddr OffSize ES Flg Lk Inf Al [ 0] NULL 00 00 00 0 0 0 [ 1] .shstrtab STRTAB 34 000142 00 0 0 1 [ 2] .text PROGBITS 000178 50 00 AX 0 0 8 [ 3] .group%__1cDstdEe GROUP 0001c8 0c 04 10 5 4 [ 4] .text%__1cDstdEen PROGBITS 0001d8 40 00 AXG 0 0 8 [ 5] .rodata PROGBITS 000218 02 00 A 0 0 1 [ 6] .comment PROGBITS 00021a 0005f1 00 0 0 1 [ 7] .stab.indexstrSTRTAB 00080b a6 00 0 0 1 [ 8] .stab.index PROGBITS 0008b4 24 0c 7 0 4 [ 9] .strtab STRTAB 0008d8 000155 00 A 0 0 1 [10] .symtab SYMTAB 000a30 a0 10 A 9 3 4 [11] .rela.textRELA 000ad0 60 0c A 10 2 4 [12] .rela.text%__1cDs RELA 000b30 18 0c AG 10 4 4 -- Eric Botcazou ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: BFD bug with elf*-sparc sections?
> Yes it does. I wonder how it is implemented differently than objcopy > and objdump... My understanding is that objcopy has far less knowledge about the ELF format than readelf, and in particular about section group like item #3. > Anyway, the bug I am reporting is that using objcopy (even just to > duplicate a .o file) is making SunPro C++ objects unlinkable. May I ask you why you need to use Binutils with SunPro C++? AFAIK Sun doesn't implement the common C++ ABI. > 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::endlhttp://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?
> 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? The latter I think, but it is obviously not (very) tested with compilers that are not compatible with the GNU compiler. > If the purpose is to work with general binaries, it seems that > 'dropping' the section group stuff is clearly a bug. Oh, sure. > I had no problems with C, but moving to C++ has been a pain. The GNU C compiler and the SunPro C compiler are supposed to be 100% binary compatible (at least we strive for that on the GNU side), so GNU Binutils is very likely compatible with the SunPro C compiler as a by-product. That's not the case for the C++ compilers. -- Eric Botcazou ___ 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
