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/c
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 descript
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 f
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 pu
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
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 nu
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 atta
