Re: BFD 2.16.1 "assertion failure" and "internal error"

[Daniel Marques]

> 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