From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14255 invoked by alias); 28 Jan 2013 14:27:07 -0000 Received: (qmail 14046 invoked by uid 22791); 28 Jan 2013 14:26:50 -0000 X-Spam-Check-By: sourceware.org Received: from aquarius.hirmke.de (HELO calimero.vinschen.de) (217.91.18.234) by sourceware.org (qpsmtpd/0.83/v0.83-20-g38e4449) with ESMTP; Mon, 28 Jan 2013 14:26:45 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id A08DF5206BF; Mon, 28 Jan 2013 15:26:42 +0100 (CET) Date: Mon, 28 Jan 2013 14:27:00 -0000 From: Corinna Vinschen To: cygwin-apps@cygwin.com Subject: Re: HEADSUP: Python 2.7 upgrade Message-ID: <20130128142642.GF14900@calimero.vinschen.de> Reply-To: cygwin-apps@cygwin.com Mail-Followup-To: cygwin-apps@cygwin.com References: <20130123185656.7e093272@YAAKOV04> <5100CB75.2000005@gmail.com> <20130124093911.GD8311@calimero.vinschen.de> <51010FC8.6030304@gmail.com> <20130124122950.GC32717@calimero.vinschen.de> <51031E65.6050902@ludens.elte.hu> <20130128103522.GA14900@calimero.vinschen.de> <51067C4B.3050604@ludens.elte.hu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <51067C4B.3050604@ludens.elte.hu> User-Agent: Mutt/1.5.21 (2010-09-15) Mailing-List: contact cygwin-apps-help@cygwin.com; run by ezmlm Precedence: bulk Sender: cygwin-apps-owner@cygwin.com List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Mail-Followup-To: cygwin-apps@cygwin.com X-SW-Source: 2013-01/txt/msg00129.txt.bz2 On Jan 28 14:25, szgyg wrote: > I didn't see the discussion on the other list. Oh, well. > > On 1/28/2013 11:35 AM, Corinna Vinschen wrote: > >On Jan 26 01:08, szgyg wrote: > >>On 1/24/2013 1:29 PM, Corinna Vinschen wrote: > >>>>>The size of the .reloc section in the file header does not indicate how > >>>>>long the relocation information in the section actually is. Usually the > >>>>>section is larger than the actual relocation info. The end of the > >>>>>relocation info is indicated by a block header with a base offset of 0 > >>>>>and a sizeof of 0, let's call it the NULL block. > >> > >>VirtualSize (offset 8 in section header) should be exact. There are > >>no terminator zero block, but can be zero section padding. > >>VirtualSize + padding = SizeOfRawData. > > > >Are you implying that rebase (or better: the included imagehelper lib) > >is doing the right thing, or not? The size of the reloc section is > >taken from SizeOfRawData. Relocations::check checks if the data is > >within a valid section. I just don't see what it's doing wrong there. > > This problem is unrelated to the segfault. > > Relocations::relocate does a strange thing that works by accident. > See this condition: > > &relocp->SizeOfBlock < (PDWORD) ((char *)relocs + size) > && relocp->SizeOfBlock != 0; > > After the last relocation block, the first half of the condition is > false if we have 0 or 1 DWORD of padding, and the second half is > false if the second DWORD of padding is 0. As paddings should be all > zeros, this condition always terminates the loop, but I wouldn't > write it in this way. A better form is something like > relocp < relocs + virtual_size > > Relocations::fix is broken, but hopefully it doesn't run on dlls not > created by dllwrap. It should set VirtualSize and zero out the > remaining part of .reloc. Right now it leaves a .reloc with an > invalid, 0-size block and additional garbage. You know that this is an open source project and patches against current CVS(*) are very welcome, right? Corinna (*) cvs -d :pserver:anoncvs@cygwin.com:/cvs/cygwiin-apps checkout rebase -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat