From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29602 invoked by alias); 28 Jun 2004 05:01:48 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 29426 invoked from network); 28 Jun 2004 05:01:40 -0000 Received: from unknown (HELO mail.aaronwl.com) (68.228.0.128) by sourceware.org with SMTP; 28 Jun 2004 05:01:40 -0000 Received: from [68.226.130.67] (cdm-68-226-130-67.laft.cox-internet.com [68.226.130.67]) by mail.aaronwl.com (8.12.11/8.12.11) with ESMTP id i5S51P8Q024566; Mon, 28 Jun 2004 05:01:26 GMT Message-ID: <40DFA627.5010009@aaronwl.com> Date: Mon, 28 Jun 2004 05:01:00 -0000 From: "Aaron W. LaFramboise" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 MIME-Version: 1.0 To: Alan Modra CC: binutils@sources.redhat.com Subject: Re: mainline ld on mingw32/pe is broken, returns 1 without error. References: <40DE22EB.7080001@aaronwl.com> <20040627040640.GM3469@bubble.modra.org> <40DE4DDA.5000304@aaronwl.com> <20040627114932.GO3469@bubble.modra.org> In-Reply-To: <20040627114932.GO3469@bubble.modra.org> X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2004-06/txt/msg00507.txt.bz2 Alan Modra wrote: > No, there's no easy way to debug this. I'd fire up gdb and see if we > get to ldwrite. I'm guessing that the problem is in bfd_final_link, > so that would mean tracing through _bfd_coff_final_link. Would you > mind taking a look? If that doesn't sound easy, could you please tar > and gzip the set of objects and libraries involved in the link and > send them to me. Well, I've found where the error is coming from, but I have no idea why. :) _bfd_coff_link_input_bfd seems to be asking for more data than is in the file. See the following: #0 cache_bread (abfd=0x3df0c8, buf=0x8904e0, nbytes=480930) at ../../../../../src/cvs/src/bfd/cache.c:100 #1 0x004326f1 in bfd_bread (ptr=0x8904e0, size=480930, abfd=0x3df0c8) at ../../../../../src/cvs/src/bfd/bfdio.c:129 #2 0x0043236d in _bfd_generic_get_section_contents (abfd=0x3df0c8, section=0x6d76ec, location=0x8904e0, offset=0, count=480930) at ../../../../../src/cvs/src/bfd/libbfd.c:706 #3 0x00426310 in bfd_get_section_contents (abfd=0x3df0c8, section=0x6d76ec, location=0x8904e0, offset=0, count=480930) at ../../../../../src/cvs/src/bfd/section.c:1355 #4 0x0044c080 in _bfd_coff_link_input_bfd (finfo=0x22fe50, input_bfd=0x3df0c8) at ../../../../../src/cvs/src/bfd/cofflink.c:2308 #5 0x0044934d in _bfd_coff_final_link (abfd=0x3dced8, info=) at ../../../../../src/cvs/src/bfd/cofflink.c:899 #6 0x00414987 in ldwrite () at ../../../../../src/cvs/src/ld/ldwrite.c:554 #7 0x00411dcb in main (argc=12, argv=0x3d2710) at ../../../../../src/cvs/src/ld/ldmain.c:481 96 nread = fread (buf, 1, nbytes, bfd_cache_lookup (abfd)); 97 /* Set bfd_error if we did not read as much data as we expected. If 98 the read failed due to an error set the bfd_error_system_call, 99 else set bfd_error_file_truncated. */ 100 if (nread < nbytes && ferror (bfd_cache_lookup (abfd))) 101 { 102 bfd_set_error (bfd_error_system_call); 103 return -1; 104 } nread = 182131 nbytes = 480930 There is a second latent bug here also. The comment indicates that bfd_error_file_truncated should be set in this case, and as near as I can tell, it is not being set, which is what is causing the mysterious silent failure. This can be easily fixed. On the other hand, I have no idea how to figure out what is actually causing the size requested to be wrong. What next? :) Aaron W. LaFramboise