From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9323 invoked by alias); 11 Sep 2006 07:26:51 -0000 Received: (qmail 9312 invoked by uid 22791); 11 Sep 2006 07:26:50 -0000 X-Spam-Check-By: sourceware.org Received: from outdoor.onevision.de (HELO outdoor.onevision.de) (212.77.172.51) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 11 Sep 2006 07:26:46 +0000 Received: from sanders.onevision.de (moonrace [212.77.172.62]) by outdoor.onevision.de (8.13.7/8.13.7/ROSCH/DDB) with ESMTP id k8B7QHVh022563; Mon, 11 Sep 2006 09:26:22 +0200 In-Reply-To: <000001c6d36e$ae673320$0100000a@bigboy> To: "Phil Lello" Cc: binutils@sourceware.org Subject: RE: PE+ and new COFF format for x86_64 target for XP64 and Vista binaries MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: Kai Tietz Date: Mon, 11 Sep 2006 07:26:00 -0000 Content-Type: text/plain; charset="US-ASCII" X-IsSubscribed: yes Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2006-09/txt/msg00068.txt.bz2 Hi Phil, Thank you for your remark. Yes, I substitute for this target XX by pex64 and the file is autogenerated by peXXigen.c to avoid code duplication. This change was needed, because otherwise I would break the IA code. Some of the used structures and the dumping methods for objdump are now adjusted for this target. E.g. the DLL-Import section has now thumbs of 8 bytes (under PE they are 4 byte size). Also the base PE header has no data_size element anymore, therefore I introduced an proper structure definition for this, because the old variant leads to wrong header sizes (May this change can be useful for IA64, too). The new define of COFF_WITH_pex64 is necessary for the include files "peicode.h", "libpei.h", "coffcode.h", and the choice of the proper target coff header file (not mixing with i386-COFF one). . Regars, i.A. Kai Tietz "Phil Lello" 08.09.2006 19:48 To "'Kai Tietz'" cc Subject RE: PE+ and new COFF format for x86_64 target for XP64 and Vista binaries Hi Kai, I notice that there is already some support for PE/PE+ in bfd/peXXigen.c, which conditionally generates either peigen.c or pepigen.c by substituting XX with either pe or pep via a sed script. A similar approach might work here too. Just my thoughts, I am new to the binutils source code. Phil > -----Original Message----- > From: binutils-owner@sourceware.org > [mailto:binutils-owner@sourceware.org] On Behalf Of Kai Tietz > Sent: 08 September 2006 11:22 > To: Pedro Alves > Cc: binutils@sourceware.org > Subject: Re: PE+ and new COFF format for x86_64 target for > XP64 and Vista binaries > > Hi Pedro, > > Thank you for your sugestions. > > Yes you are right, that the major changes are the sizes for > .idata$ for the changed thumb sizes. The reason for the > duplication of the code is that otherwise pe and pe+ won't be > linkable into one ld binary reasoned by global method names > and variables. It is more the question about supporting both > targets together or not. > The other solution would be to make out of pep_dll.c a stub > file simply defining the different global names and pack the > implementation within pe_dll.c. This solution leads to a > macro desert code, but it would help. > > Regards, > i.A. Kai Tietz > > > > > Pedro Alves Sent by: > binutils-owner@sourceware.org > 08.09.2006 11:50 > > To > Kai Tietz > cc > binutils@sourceware.org > Subject > Re: PE+ and new COFF format for x86_64 target for XP64 and > Vista binaries > > > > > > > Hi Kai, > > I'm no binutils maintainer, but I got a few sugestions. > > Kai Tietz wrote: > > Hallo, > > > > This is a port of binutils-2.17 for COFF-format x86-64 > (AMD64) and the > PE+ > > for Windows XP64 and Vista EXE/DLL. The target is named > x86_64-pc-mingw64. > > To get this into binutils, you will need to forward port your changes > to the current version in CVS. The 2.17 branch should only take > important bug fixes. > > > > I enabled windres and dlltool for this target. For the tool > objdump the > > processing and printing methods for DLL-imports are > adjusted (they are > now > > 8 bytes long :( ) > > > > > > I made a copy of the pe_dll(.c&.h) as pep_dll(.c&.h) to minimize > > intersections. > > Looking and diffing at the pep_dll.{c|h} and pep.em files, I > notice that > the changes related to pe_dll.{c|h} and pe.em, excluding the pe_* to > pep_* renamings, could be minimized to just a few places. > We should avoid duplicating files this size. I haven't looked at the > other parts of the patch, but possibly, the same could apply. > > >May these files can be merged. > > > > I would say, yes please. > > > Hope this helps, > Cheers, > Pedro Alves > > > > In the "include/coff/external.h" I introduced the proper > PE+ external > > aouthdr structure without the data_start member. Because this > non-existing > > member breaks the > > size of the PEPAOUT structure in include/coff/pe.h. > > > > For the bfd/pexxigen.c template I used the pex64 name alias for > > generation. > > > > I added the following new files: > > bfd/coff-x86_64.c > > bfd/pe-x86_64.c > > bfd/pei-x86_64.c > > gas/config/te-pep.h > > include/coff/x86_54.h > > ld/pep_dll.c > > ld/pep_dll.h > > ld/emulparams/i386pep.sh > > ld/emultempl/pep.em > > ld/scripttempl/pep.sc > > > > > > I tested the ld of this target by MSVC object-files and by > (a patched) > gcc > > object-files (using this gas) linking against MS-Runtime-libraries. > > > > i.A. Kai Tietz > > > > > > > __________ NOD32 1.1743 (20060907) Information __________ > > This message was checked by NOD32 antivirus system. > http://www.eset.com > >