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
