Date:	Thu, 8 Aug 1996 10:34:28 +0200 (METDST)
From:	Robert Hoehne <robert DOT hoehne AT mathematik DOT tu-chemnitz DOT de>
To:	Charles Sandmann <sandmann AT clio DOT rice DOT edu>
Cc:	djgpp-workers AT delorie DOT com
Subject:	Re: Testing binutils 2.7
In-Reply-To:	<9608061606.AA14095@clio.rice.edu>
Message-Id:	<Pine.HPP.3.91.960808101559.4619D-100000@newton.mathematik.tu-chemnitz.de>
Mime-Version:	1.0

On Tue, 6 Aug 1996, Charles Sandmann wrote:

> The "2.5.2" behavior is correct.  This is a configuration issue when building
> the tools - DJ found and fixed it late in the V2 beta processes.  I can't
> find the fix right now.
>

I found it now!

tc-i386.c:326:#if !defined(OBJ_AOUT) && !defined(__DJGPP__)
                                     ^^^^^^^^^^^^^^^^^^^^^^

DJ has changed this file without any notice (or have you sent this
to the FSF and they didn't integrate it?)

Now I also fixed this and the alignment is now correct.
But an other thing. Eli asked, to look if it is possible to change
the BFD library for support of stubbed COFF images. I did
it with a little trick, because the BFD-routines do not support
file handling with files which have an offset where the real image
start (or do they have and I didn't found it?). My trick is, that
the COFF image is read completely in memory and is marked as
BFD_IN_MEMORY and then the normal COFF code is called with that 
BFD-structure.

Reading of exe's now work with this, but is it good to do this in that
way, because the complete file have to read in memory.

The other problem is when writing this bfd-target. When i do

strip foo.exe

the resulting file foo.exe has no symbols (that's correct) but it
has also no stub, and I think this is not correct.

The next problem: If we decide to integrate my or a similiar feature
to the BFD-libray, to wich version we sholud do it, because the
BFD-library from GDB 4.16 is, as far as I know 2.6, and I did the changes
with 2.7.
 
Robert

- Raw text -