> 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/
> 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 jus
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
> 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 compiler
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
