From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22271 invoked by alias); 17 Aug 2006 05:05:44 -0000 Received: (qmail 22254 invoked by uid 22791); 17 Aug 2006 05:05:43 -0000 X-Spam-Check-By: sourceware.org Received: from pool-71-248-179-229.bstnma.fios.verizon.net (HELO cgf.cx) (71.248.179.229) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 17 Aug 2006 05:05:42 +0000 Received: by cgf.cx (Postfix, from userid 201) id 7C1E913C049; Thu, 17 Aug 2006 01:05:40 -0400 (EDT) Date: Thu, 17 Aug 2006 08:09:00 -0000 From: Christopher Faylor To: pedro_alves@portugalmail.pt, binutils@sourceware.org Subject: Re: 2006-05-11 change to pe-dll.c breaks Windows DLLs Message-ID: <20060817050540.GA19240@trixie.casa.cgf.cx> Mail-Followup-To: pedro_alves@portugalmail.pt, binutils@sourceware.org References: <20060817050036.GA19122@trixie.casa.cgf.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060817050036.GA19122@trixie.casa.cgf.cx> User-Agent: Mutt/1.5.11 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-08/txt/msg00194.txt.bz2 On Thu, Aug 17, 2006 at 01:00:36AM -0400, Christopher Faylor wrote: >The change following the "Huh?" below causes problems for x86 Windows DLLs. Btw, the problem that I'm seeing is that Windows DLLs produced by ld can no longer be relocated -- which sort of makes sense given this change. cgf >Index: pe-dll.c >=================================================================== >RCS file: /cvs/src/src/ld/pe-dll.c,v >retrieving revision 1.83 >retrieving revision 1.84 >diff -u -r1.83 -r1.84 >--- pe-dll.c 31 Jan 2006 22:08:14 -0000 1.83 >+++ pe-dll.c 11 May 2006 08:48:58 -0000 1.84 >@@ -1131,8 +1137,13 @@ > int nsyms, symsize; > > /* If it's not loaded, we don't need to relocate it this way. */ >+#if 0 /* Some toolchains can generate .data sections without a SEC_LOAD flag but with relocs. */ > if (!(s->output_section->flags & SEC_LOAD)) > continue; >+#endif >+ /* Huh ? */ >+ if (strncmp (bfd_get_section_name (abfd, s), ".idata",6) == 0) >+ continue; > > /* I don't know why there would be a reloc for these, but I've > seen it happen - DJ */ > >I don't understand the rationale for the change. How can we skip idata$6 sections? > >And, as a meta-issue the "#if 0" and /* Huh ? */ comment don't provide >a lot of information into what is going on here. Shouldn't there be >some more informative comments there? > >This is the ChangeLog from this change: > >2006-05-11 Pedro Alves > > * pe-dll.c (autofilter_symbollist): Add Dllmain, > DllMainCRTStartup, _DllMainCRTStartup and .text. > (autofilter_liblist): Add libcegcc. > (autofilter_symbolprefixlist): Add __imp_ and .idata$. > (generate_reloc): Do not skip sections without a SEC_LOAD flag, > they can still contain relocs that need processing. > Skip the .idata$6 section. > (jmp_arm_bytes): New array: Contains byte codes for an ARM jump. > (make_one): Use the new array. > (make_import_fixup_entry): Use .idata$2 instead of .idata$3. > * emultempl/pe.em (MajorSubsystemVersion): Set to 3 for armpe. > >Pedro can you explain why this is needed? Should it possibly be >conditionalized only for your ARM target? > >cgf >