public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Hanzac Chen <hanzac@gmail.com>
To: binutils@sources.redhat.com
Subject: Re: Strange flag in WIN32 PECOFF
Date: Tue, 15 Mar 2005 09:51:00 -0000	[thread overview]
Message-ID: <4236A621.10801@gmail.com> (raw)
In-Reply-To: <42362AC0.7050808@aaronwl.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

  parent reply	other threads:[~2005-03-15  9:51 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-14 23:35 Hanzac Chen
2005-03-15  0:22 ` Aaron W. LaFramboise
2005-03-15  3:20   ` DJ Delorie
2005-03-15  9:51   ` Hanzac Chen [this message]
2005-03-15 10:26     ` Aaron W. LaFramboise
2005-03-15 11:05       ` Hanzac Chen
2005-03-15 18:30       ` DJ Delorie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4236A621.10801@gmail.com \
    --to=hanzac@gmail.com \
    --cc=binutils@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).