Strange flag in WIN32 PECOFF

Strange flag in WIN32 PECOFF

[Hanzac Chen]

Hi, Guys

I found the latest version of binutils (GNU binutils 2.15.94
20050118) will produce a PECOFF object with IMAGE_FILE_32BIT_MACHINE
(aka: F_AR32WR) on, in the field Characteristics (aka: f_flags) of
the COFF File Header.

But in previous versions (like 2.14 if I remembered clear), this
flag will be turn off.

I think it's strange and inconsistent, I hope you can give me
some explanation. BTW: I'm writing a COFF object parser, and
want to support two kinds of COFF, one is from MingW and the
other from DJGPP. So I need to rely on the difference of the
file's format. I know that the two kinds of formats' absolute
relocation method are different. Does the F_AR32WR flag I mentioned
above has some relation with this relocation difference?

GOoD BYE,
Hanzac

Re: Strange flag in WIN32 PECOFF

[Aaron W. LaFramboise]

Hanzac Chen wrote:

> I found the latest version of binutils (GNU binutils 2.15.94
> 20050118) will produce a PECOFF object with IMAGE_FILE_32BIT_MACHINE
> (aka: F_AR32WR) on, in the field Characteristics (aka: f_flags) of
> the COFF File Header.
> 
> But in previous versions (like 2.14 if I remembered clear), this
> flag will be turn off.

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 think it's strange and inconsistent, I hope you can give me
> some explanation. BTW: I'm writing a COFF object parser, and
> want to support two kinds of COFF, one is from MingW and the
> other from DJGPP. So I need to rely on the difference of the
> file's format. I know that the two kinds of formats' absolute
> relocation method are different. Does the F_AR32WR flag I mentioned
> above has some relation with this relocation difference?

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.

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).


Aaron W. LaFramboise

Re: Strange flag in WIN32 PECOFF

[DJ Delorie]

> 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.

Re: Strange flag in WIN32 PECOFF

[Hanzac Chen]

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

Re: Strange flag in WIN32 PECOFF

[Aaron W. LaFramboise]

Hanzac Chen wrote:

> 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. :-)

I would suspect, without really knowing, that either PECOFF or DJGPP's
COFF implementation is incorrect with regards to the original COFF
specification.  This is probably the root of the problem.  However, I
don't think it is possible to fix this.

One would assume, though, there would be some way to distinguish PECOFF
objects from other sorts of objects.  I can't think of any particular
method offhand, though.  You might try assembling an object with
binutils assemblers for both targets, and seeing if objdump reports any
interesting differences.


Aaron W. LaFramboise

Re: Strange flag in WIN32 PECOFF

[Hanzac Chen]

Hi, Aaron

Aaron W. LaFramboise wrote:
> ...
> I would suspect, without really knowing, that either PECOFF or DJGPP's
> COFF implementation is incorrect with regards to the original COFF
> specification.  This is probably the root of the problem.  However, I
> don't think it is possible to fix this.
> ...

Is it because that the PECOFF format should follow the Microsoft's
specification? If that, I don't think it will do good. Moreover, barely 
the compatibility in the formats is not enough, MSVC produces objects
that have too much *features* especially the C++ ones. IMHO, only the
PE *executale* file strictly following the specification is enough.
and the objects could be compatible with the DJGPP's.

only suggestion,
Hanzac

Re: Strange flag in WIN32 PECOFF

[DJ Delorie]

> I would suspect, without really knowing, that either PECOFF or
> DJGPP's COFF implementation is incorrect with regards to the
> original COFF specification.

Since COFF is otherwise pretty much dead, "correct" is a nebulous
term.  DJGPP's COFF matched what all the other binutils coff's were
doing back then (i386-coff was a popular embedded target), but that
doesn't mean it's "correct".  PECOFF matches what Microsoft was
producing for Windows, but that doesn't mean it's "correct" either.

The binutils tool "just know" which format they're expecting, so it's
never been a problem before.  In general, you can't just link DJGPP
objects and PECOFF objects together.  COFF differences aside, the
code's semantics just won't merge well.