Re: Strange flag in WIN32 PECOFF

[Hanzac Chen <hanzac at gmail dot com>]

Hi,

Aaron W. LaFramboise wrote:
> Correct.  This is due to Jeff Muizelaar's patch
> <http://sources.redhat.com/ml/binutils/2003-07/msg00215.html>.
>
> All i386-pe executables should have this flag set to indicate the binary
> is for a 32-bit machine.  The PECOFF specification seems to indicate
> that this is the right thing.  In addition, Microsoft's linker,
> Borland's linker, and lcclnk (among others, I'm sure) all set this flag.

I see, thanks for clearing-up this problem.

> I don't think this flag will change the behavior of the relocations
> because the each relocation type is specified to operate on a specific
> word size.

I think possibly you misunderstood me, I mean object-level outputs of
binutils not the final executables. When at the object-level, both the
LD targeted to pe-i386 and targeted to coff-go32 will output very-alike
COFF objects. and Their only difference at least I can make sure is that
the abosulte relocation method: in coff-go32 the reloc, which needs
this relocation, only need to add the base address to its related
mem-address. while in pe-i386, both the base address and the relocated
symbol's offset should be added to that mem-address.

> To be honest, I don't know anything about DJGPP's COFF, but its my
> understanding that its significantly different from PECOFF.  I don't
> think DJGPP implements any of the PE-specific parts of COFF.
>
> If you're trying to distinguish PECOFF objects from other sorts of COFF
> objects, I think you'll want to look for the magic number in the
> optional header (which isn't optional in PE).

As I metioned above, that PECOFF objects don't have that optoinal header
if they are not the final executables. So it's hard to distinguish
the PECOFF and DJGPP's COFF, if I can't rely on the flag of the COFF
header. Moreover I can't rely on the reloc-type, either.

So this is really confusing.

DJ Delorie wrote:
> > I don't think DJGPP implements any of the PE-specific parts of COFF.
>
>
> It doesn't.  DJGPP's coff support predates all of the PE work in
> binutils.

So it's the PE work's problem. :-)
But anyway I think since the two COFF outputs are supported by the
binutils, they at least should be compatible when they are not the
final executables so that they can be linked by the both binutils'
targets. It will be great. and it will be easier for those who are
drilling in the OS level and linker level. :-)

anyway, Thanks for bringing the great work!

GOoD BYE,
Hanzac