bfd/peigen.c problems and fix

[Donn Terry]

I've been at MS far less time than I've been working on Interix
(we got bought last September).  The goal of MS compatability was
always there (we can, and regularly do, intermix the two compilers,
altho there are some things you can do with gcc/ld that don't go
back thru LINK.EXE.)

If that's the case, then some other change that I made hasn't gotten
applied yet, because everything that should be an RVA is an RVA
with all my patches applied.

(To answer your last question first:) COFF_WITH_PE applies to .obj
files (or .o on Interix).  COFF_IMAGE_WITH_PE applies to executables.
(They're different file formats.)  Here's what I get from
objdump on a .o:

hello.o:     file format pe-i386
architecture: i386, flags 0x0000003d:
HAS_RELOC, HAS_LINENO, HAS_DEBUG, HAS_SYMS, HAS_LOCALS
start address 0x00000000

It *is* set on a PEI (Image/.exe) file.

As far as the other... I've glanced thru my patches (don't
really have time to do it thoroughly at this moment) and 
it would appear that in cofflink.c/_bfd_generic_relocate_section
that I have some carefully crafted code dealing with whether
image_base is applied (Ian, as I said, has a pre-September
copy); that may be the difference.  Also, Ian and I had not
resolved an issue about a lot obj_pe() tests that affected
exactly how relocations are handled.

Martin - can you put a sample where I can find it so I can
look at what you're actually getting.  (Along with such details
as configuration.)  I may be able to tell more once I can see
exactly what's in the file.

Donn


> -----Original Message-----
> From: Alan Modra [ mailto:alan@linuxcare.com.au ]
> Sent: Wednesday, May 03, 2000 4:47 PM
> To: Donn Terry
> Cc: Martin Kahlert; binutils@sourceware.cygnus.com
> Subject: RE: bfd/peigen.c problems and fix
> 
> 
> On Wed, 3 May 2000, Donn Terry wrote:
> 
> > In looking at an objdump -p of a MSVC-generated a.out 
> (yes... on Interix
> > that statement makes sense) the data offset column for the 
> Data Directory
> > contains values which do NOT contain the value of ImageBase 
> (that is they
> > are RVAs).  The change you propose would change them into 
> absolute VAs
> > (unless theres additional magic I'm not seeing.  Here's a 
> cut of what I get
> > (from MSVC/LINK.EXE generated code):
> > 
> > Entry 0 00000000 00000000 Export Directory [.edata (or 
> where ever we found
> > it)]
> > Entry 1 00012000 00000028 Import Directory [parts of .idata]
> > Entry 2 00000000 00000000 Resource Directory [.rsrc]
> > Entry 3 00000000 00000000 Exception Directory [.pdata]
> > Entry 4 00000000 00000000 Security Directory
> > Entry 5 00013000 00000594 Base Relocation Directory [.reloc]
> > Entry 6 0000f020 00000054 Debug Directory
> > Entry 7 00000000 00000000 Description Directory
> > Entry 8 00000000 00000000 Special Directory
> > Entry 9 00000000 00000000 Thread Storage Directory [.tls]
> > Entry a 00000000 00000000 Load Configuration Directory
> > Entry b 00000000 00000000 Bound Import Directory
> > Entry c 000120a4 0000007c Import Address Table Directory
> > Entry d 00000000 00000000 Reserved
> > Entry e 00000000 00000000 Reserved
> > Entry f 00000000 00000000 Reserved
> >            ^
> >            This column
> > 
> > If I understand the "add_data_entry" part of your proposed change
> > correctly, it would have the effect of adding 0x400000 (in 
> effect) to every
> > value in "This column" above. For maximal MS compatability, 
> that's wrong.
> 
> Actually, my change does just the opposite of what you're 
> saying.  (How
> long have you been working at Microsoft?  Grin)  The current 
> code has the
> 0x400000 added in because section->vma is set to 0x40xxxx.  
> Subtracting
> off ImageBase turns what was an absolute address back into a 
> relative one.
> 
> > (I
> > believe things "work" with ImageBase added in, in most 
> instances, however
> 
> The report I had from Martin Kahlert, was that this isn't so.  He was
> testing on WinNT.  My few experiments using "objdump -p" were 
> with .exe
> files from Windows 95.
> 
> Incidentally, why this change too?
> 1999-09-06  Donn Terry  <donn@interix.com>
> 	* coffcode.h
> 	(coff_write_object_contents): Don't set F_AR32W(R)? if
> 	COFF_WITH_PE.
> 
> The Windows95 exe files I looked at all had this flag set.
> 
> -- 
> Linuxcare.  Support for the Revolution.
> 
>