From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30032 invoked by alias); 23 Jan 2017 14:11:13 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 30004 invoked by uid 89); 23 Jan 2017 14:11:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy=chronic, H*RU:sk:host86-, Hx-spam-relays-external:sk:host86-, H*r:sk:host86- X-HELO: out1-smtp.messagingengine.com Received: from out1-smtp.messagingengine.com (HELO out1-smtp.messagingengine.com) (66.111.4.25) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 23 Jan 2017 14:11:01 +0000 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id E616C20AA1; Mon, 23 Jan 2017 09:10:59 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Mon, 23 Jan 2017 09:10:59 -0500 X-ME-Sender: Received: from [192.168.1.102] (host86-166-190-63.range86-166.btcentralplus.com [86.166.190.63]) by mail.messagingengine.com (Postfix) with ESMTPA id 789A57E033; Mon, 23 Jan 2017 09:10:59 -0500 (EST) From: Jon Turney Subject: Re: Out of date GNU binutils, and (slightly) broken binutils 2.27 To: "Franchuk, Alex" References: <5882821D.6090000@LGSInnovations.com> Cc: cygwin@cygwin.com Message-ID: <01e5c3e0-96e8-6efc-fdce-ec2e9d168e1a@dronecode.org.uk> Date: Mon, 23 Jan 2017 14:11:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <5882821D.6090000@LGSInnovations.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2017-01/txt/msg00285.txt.bz2 On 20/01/2017 21:33, Franchuk, Alex wrote: > I've been responsible for porting a large [primarily] C++ project from > Linux to Cygwin. This project generates object files at one point in the > build process which exceed the object file symbol count limit (around > 32k, but if I recall correctly there was actually a binutils bug > limiting this further to 16k). As such, I needed an assembler and linker > that supported the windows big-obj format. That was added in more recent > versions of GNU binutils, however the version that is available in the > Cygwin repository is discouragingly old. So the first point I want to > make is to ask whether the maintainers of Cygwin binutils can be pinged > to update the supported version, or to know why the last supported > version is from 2014 (is there something that breaks with newer versions?). If I understood correctly, 'nm -l' suffers from a chronic slowdown on x86 (but not x86_64). This makes the cygport stage which builds debuginfo packages take forever for large projects. No-one has had the time to investigate this problem. > The next step I took was to get a recent version (2.27) that does > support big-obj, compile it on the system, point gcc toward that > installation, and try to proceed from there. This fixed the big-obj > issue, and for the most part lots of the sub-projects were working just > fine. But one sub-project in particular is having an issue: the > resulting binary (a dll, in this case) has a flaw in the import lookup > table (.idata subsection). The import lookup table of one > runtime-dependent DLL is overwriting the null entry that *ends* the > previous DLL's table. So, the previous DLL tries to link with a symbol > that is actually contained in the other DLL, while the other DLL still > correctly points to needing that symbol as well. In other words, this > makes it impossible to use the resulting DLL, because it has a dependent > symbol that will never be resolved correctly. It's worth noting that > lots of other things link correctly without this bug, and other DLLs > within that file do not have import lookup tables that overrun each > other. I thought it would be reasonable to send to this mailing list > because, from what I read in the binutils source, it seemed like most of > the pe/pe+ code that has been added to binutils was from Cygwin > developers. I tried to find the root of the problem, but after hours of > searching and debugging the linker and BFD code, I haven't found the > source of the discrepancy. Please report this issue on the binutils bugzilla. Please include a test case, or at least an example of a defective PE file, and say what you think it should look like. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple