From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18207 invoked by alias); 5 May 2006 02:50:10 -0000 Received: (qmail 18188 invoked from network); 5 May 2006 02:50:02 -0000 Received: from unknown (195.23.133.217) by sourceware.org with QMTP; 5 May 2006 02:50:02 -0000 Received: (qmail 1739 invoked from network); 5 May 2006 02:50:01 -0000 Received: from unknown (HELO mailfrt08.isp.novis.pt) ([195.23.133.200]) (envelope-sender ) by mailrly07.isp.novis.pt with compressed SMTP; 5 May 2006 02:50:01 -0000 Received: (qmail 22863 invoked from network); 5 May 2006 02:49:39 -0000 Received: from unknown (HELO mamas-laptop) ([195.23.225.144]) (envelope-sender ) by mailfrt08.isp.novis.pt with SMTP; 5 May 2006 02:49:39 -0000 Received: from localhost ([127.0.0.1]) by mamas-laptop with esmtp (Exim 4.60) (envelope-from ) id IYRUIV-0006V8-7P for binutils@sourceware.org; Fri, 05 May 2006 03:49:43 +0100 Message-ID: <445ABD43.9050006@portugalmail.pt> Date: Fri, 05 May 2006 02:50:00 -0000 From: Pedro Alves User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: binutils@sourceware.org Subject: Re: arm-wince-pe, dll auto-importing broken when References: <445AAF0A.6000402@portugalmail.pt> <445AB263.507@portugalmail.pt> <20060505021716.GA16612@nevyn.them.org> <445AB9DD.5040003@portugalmail.pt> In-Reply-To: <445AB9DD.5040003@portugalmail.pt> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 0618-2, 04-05-2006), Outbound message X-Antivirus-Status: Clean 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-05/txt/msg00102.txt.bz2 Pedro Alves wrote: > Daniel Jacobowitz wrote: >> On Fri, May 05, 2006 at 03:03:15AM +0100, Pedro Alves wrote: >> >>> I have to reply to myself, but I just noticed what probably the real >>> problem is. I was close, but not there. >>> >>> SORT(*)(.idata$3) >>> .idata$3 0x0001503c 0x14 >>> /usr/local/lib/gcc/arm-wince-pe/4.1.1/../../../../arm-wince-pe/lib/zlibce.lib(zlibce.dll.c) >>> >>> 0x0001503c __NULL_IMPORT_DESCRIPTOR >>> .idata$3 0x00015050 0x14 fu000001.o >>> 0x00015064 0x4 LONG 0x0 >>> 0x00015068 0x4 LONG 0x0 >>> 0x0001506c 0x4 LONG 0x0 >>> 0x00015070 0x4 LONG 0x0 >>> 0x00015074 0x4 LONG 0x0 >>> >>> The os loader will see __NULL_IMPORT_DESCRIPTOR, which is an import >>> descriptor terminator, and will not process the fu000001.o >>> import descriptor. >>> So I guess I should be looking at why isn't __NULL_IMPORT_DESCRIPTOR >>> discarded by default. >>> Any hints? >>> >> >> Now, I don't know the first thing about PE, so I'm guessing. But >> what's in fu00001.o that you want to get processed? The comments in >> dlltool say .idata$3 are just supposed to be terminators. >> >> > It is related to auto importing. It contains the auto import fixup > entries. It consists of an entry of type IMAGE_IMPORT_DESCRIPTOR which > takes > 0x14 bytes. > See comments at the top of pe-dll.c, and also make_import_fixup_entry > in that same file for where it is generated. > > The loader will process the the null terminated array of import > descriptors. Since __NULL_IMPORT_DESCRIPTOR is filled with 0, > the loader will stop processing there instead of at that, > > 0x00015064 0x4 LONG 0x0 > 0x00015068 0x4 LONG 0x0 > 0x0001506c 0x4 LONG 0x0 > 0x00015070 0x4 LONG 0x0 > 0x00015074 0x4 LONG 0x0 > Which is really the same as an unnamed __NULL_IMPORT_DESCRIPTOR. > Actually, shouldn't auto import fixup entries be stored in .idata$2 instead of .idata$3 subsection? Cheers, Pedro Alves