* Failing 'make check' for non-Cygwin GMP-ECM package
@ 2016-02-06 9:32 Mark Geisert
2016-02-06 10:05 ` Achim Gratz
0 siblings, 1 reply; 5+ messages in thread
From: Mark Geisert @ 2016-02-06 9:32 UTC (permalink / raw)
To: cygwin
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'.
Debugging with gdb, I see something odd and would appreciate any thoughts
on where I should take this issue. The faulting source line is
mpmod.c:343 which reads:
REDC2(rp, cp, np, nn, invm);
This macro expands to a call to __gmpn_redc_2(). That function is at an
address above the 4GB line (this is on Win7 64-bit) as seen here:
(gdb) i func ^__gmpn_redc_2$
All functions matching regular expression "^__gmpn_redc_2$":
Non-debugging symbols:
0x00000003fcbee9e8 __gmpn_redc_2
But the instructions generated for that source line look like this:
(gdb) x/7i $rip
=> 0x1004166c0 <__ecm_mpres_get_z+240>: mov 0x10(%rdi),%rax
0x1004166c4 <__ecm_mpres_get_z+244>: mov %rbp,%r9
0x1004166c7 <__ecm_mpres_get_z+247>: mov %r13,%r8
0x1004166ca <__ecm_mpres_get_z+250>: mov %r12,%rcx
0x1004166cd <__ecm_mpres_get_z+253>: mov %rax,0x20(%rsp)
0x1004166d2 <__ecm_mpres_get_z+258>: callq 0xfcbee9e8
0x1004166d7 <__ecm_mpres_get_z+263>: test %rax,%rax
Notice how the callq instruction has a truncated address. I thought maybe
there's an issue with displaying that instruction (unlikely I know) so I
stepped by instruction, but no, the truncated address is actually hit:
(gdb) si
0x00000001004166c4 343 REDC2(rp, cp, np, nn, invm);
(gdb)
0x00000001004166c7 343 REDC2(rp, cp, np, nn, invm);
(gdb)
0x00000001004166ca 343 REDC2(rp, cp, np, nn, invm);
(gdb)
0x00000001004166cd 343 REDC2(rp, cp, np, nn, invm);
(gdb)
0x00000001004166d2 343 REDC2(rp, cp, np, nn, invm);
(gdb)
0x00000000fcbee9e8 in ?? ()
(gdb)
Program received signal SIGSEGV, Segmentation fault.
0x00000000fcbee9e8 in ?? ()
(gdb)
I'm current on all Cygwin packages such as binutils. Does the above look
like a linker issue or linker misuse (e.g. missing option)? Could there
be a mismatch of object file arch between my just-built GMP-ECM and
Cygwin's libgmp-devel? Or something else? If it doesn't seem like a
Cygwin issue I can take it upstream to Inria.
Thanks much,
..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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Failing 'make check' for non-Cygwin GMP-ECM package
2016-02-06 9:32 Failing 'make check' for non-Cygwin GMP-ECM package Mark Geisert
@ 2016-02-06 10:05 ` Achim Gratz
2016-02-07 23:53 ` Mark Geisert
0 siblings, 1 reply; 5+ messages in thread
From: Achim Gratz @ 2016-02-06 10:05 UTC (permalink / raw)
To: cygwin
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.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
--
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Failing 'make check' for non-Cygwin GMP-ECM package
2016-02-06 10:05 ` Achim Gratz
@ 2016-02-07 23:53 ` Mark Geisert
2016-02-08 7:59 ` Mark Geisert
0 siblings, 1 reply; 5+ messages in thread
From: Mark Geisert @ 2016-02-07 23:53 UTC (permalink / raw)
To: cygwin
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.
Regards,
..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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Failing 'make check' for non-Cygwin GMP-ECM package
2016-02-07 23:53 ` Mark Geisert
@ 2016-02-08 7:59 ` Mark Geisert
2016-02-10 19:32 ` Failing 'make check' for non-Cygwin GMP-ECM package -- workaround Mark Geisert
0 siblings, 1 reply; 5+ messages in thread
From: Mark Geisert @ 2016-02-08 7:59 UTC (permalink / raw)
To: cygwin
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 don't know if the first bug could be caused by improper compiler options or
whatnot. Here's the gcc invocation for that one object file:
/bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I./x86_64
-pipe -g -O2 -march=haswell -MT libecm_la-mpmod.lo -MD -MP -MF
deps/libecm_la-mpmod.Tpo -c -o libecm_la-mpmod.lo `test -f 'mpmod.c' || echo
'./'`mpmod.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I./x86_64 -pipe -g -O2
-march=haswell -MT libecm_la-mpmod.lo -MD -MP -MF .deps/libecm_la-mpmod.Tpo -c
mpmod.c -o libecm_la-mpmod.o
Configure does know it's building for x86_64. I am up to date on binutils and
this is on Cygwin 2.4.1, Win7 64-bit.
..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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Failing 'make check' for non-Cygwin GMP-ECM package -- workaround
2016-02-08 7:59 ` Mark Geisert
@ 2016-02-10 19:32 ` Mark Geisert
0 siblings, 0 replies; 5+ messages in thread
From: Mark Geisert @ 2016-02-10 19:32 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2016-02-10 19:32 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-02-06 9:32 Failing 'make check' for non-Cygwin GMP-ECM package Mark Geisert
2016-02-06 10:05 ` Achim Gratz
2016-02-07 23:53 ` Mark Geisert
2016-02-08 7:59 ` Mark Geisert
2016-02-10 19:32 ` Failing 'make check' for non-Cygwin GMP-ECM package -- workaround Mark Geisert
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).