X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=R6DZH/qLEGrqQtwa
	UUyzFoyPmF8/CpjMCxNynfPpkp+JVhy7dmAhj+D0dkgrzrq0FPctQBIVorsfe/3e
	kWUvb26bnOzP2iU/ePkVu31pNUnTI1f28dTxv6VjRud3XSa0TDt/vt8xjti95eW2
	4rRX2VnAO+ZlcHo9nNQfr+vSvus=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; s=default; bh=yDU+APg5Fv5ytXD2fTBUOh
	CO0Q0=; b=K9xjtSiNOR4peb9xAWvbiUgkYKuyBxdpvYeifXOebth53B85oabJCM
	hmW6is/ML45dI3HRgsWV3QYQIivA3nd8PZNKsOl7oYsyJY9fWEL5CAZBXlrk+dI1
	ps0PPWalDf1m2MM3ZCQvkYvcmzL4FKB7Nt0VEP4j1xWqI8dRs4t3Q=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=1.4 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 spammy=H*r:8.12.11, H*RU:!192.168.1.100!, Hx-spam-relays-external:!192.168.1.100!, H*r:ip*192.168.1.100
X-HELO: m0.truegem.net
Subject: Re: Failing 'make check' for non-Cygwin GMP-ECM package -- workaround
To: cygwin AT cygwin DOT com
References: <Pine DOT BSF DOT 4 DOT 63 DOT 1602060102510 DOT 92842 AT m0 DOT truegem DOT net> <87d1saqhlj DOT fsf AT Rainer DOT invalid> <56B7D8FA DOT 1040501 AT maxrnd DOT com> <56B84AEC DOT 4020405 AT maxrnd DOT com>
From: Mark Geisert <mark AT maxrnd DOT com>
Message-ID: <56BB9065.5070406@maxrnd.com>
Date: Wed, 10 Feb 2016 11:32:53 -0800
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 SeaMonkey/2.39
MIME-Version: 1.0
In-Reply-To: <56B84AEC.4020405@maxrnd.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Mark Geisert wrote:
> Mark Geisert wrote:
>> Achim Gratz wrote:
>>> Mark Geisert writes:
>>>> I'm seeing an odd issue after building the GMP-ECM 6.4.4 package from
>>>> Inria.  I downloaded the .tar.gz file and unpacked, ran configure,
>>>> then make and 'make check'.  I get a SIGSEGV from a test using ecm.exe
>>>> as part of 'make check'.
>>>
>>> It seems that this release is three years old.  Did you try autoreconf
>>> or just configure?  If the latter, it may simply not recognize the
>>> current Cygwin correctly in its configury.
>>
>> Thanks for the idea but trying it didn't change the symptoms.  With more
>> debugging this seems to me like some kind of dynamic relocation issue so I'm
>> looking further in that direction within the Cygwin DLL.
>
> Replying to myself...  Yes, there appear to be two separate bugs colluding to
> break things the way I'm seeing.  First, the application's object file has
> R_X86_64_PC32 relocation markers for functions it wants to pull in from
> cyggmp-10.dll.  These relocation entries apparently allow for only 4 bytes of
> address.
>
> Second, the relocation that actually needs doing in this testcase results in
> addresses above 4GB, so they need more than 4 bytes to be stored.  There is code
> in Cygwin's pseudo-reloc.cc to check for this situation but it is being skipped
> because __OPTIMIZE__ has been #define'd somewhere by the procedure that builds
> Cygwin.  Instead, the relocated address gets truncated before being written back
> to memory, rather than provoking the error report "Invalid relocation. [...]
> doesn't fit into 32 bits".

I've worked around the first "bug" by rebasing the Cygwin gmp DLLs.  It seems 
those R_X86_64_PC32 relocation markers I had thought problematic are ubiquitous 
and work without issue the vast majority of the time.  They are used to relocate 
addresses up to 2GB above or below the site of the relocation.  It's not working 
here but I can't see what's so special about this case.  The relocation sites 
are in a static library FWIW.  But in any case, on my system the original DLLs 
were located here:

/usr/bin/cyggmpxx-4.dll                   base 0x0003fcee0000 size 0x0000e000
/usr/bin/cyggmp-10.dll                    base 0x0003fcef0000 size 0x0008c000

and I rebased them to here:

/usr/bin/cyggmpxx-4.dll                   base 0x0000fcee0000 size 0x0000e000
/usr/bin/cyggmp-10.dll                    base 0x0000fcef0000 size 0x0008c000

and that did the trick.  I'll take the second bug to the developers list.
Cheers,

..mark


--
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