[PATCH 64bit] Fix ONDEE for 64bit

[PATCH 64bit] Fix ONDEE for 64bit

[Yaakov]

[-- Attachment #1: Type: text/plain, Size: 293 bytes --]

Corinna,

More fun from our good friend, size_t:

Because operator new (in its various forms) takes a size_t argument, it
is mangled differently on x86_64 above and beyond the common leading
underscore issue.  Patches for winsup/cygwin and gcc (on top of your
latest patch) attached.


Yaakov

[-- Attachment #2: cygwin-ondee-64bit.patch --]
[-- Type: text/x-patch, Size: 3663 bytes --]

2013-03-04  Yaakov Selkowitz  <yselkowitz@...>

	* cygwin64.din: Fix mangled operator new names for size_t==long.
	* libstdcxx_wrapper.cc: Ditto for x86_64.

Index: cygwin64.din
===================================================================
RCS file: /cvs/src/src/winsup/cygwin/Attic/cygwin64.din,v
retrieving revision 1.1.2.9
diff -u -p -r1.1.2.9 cygwin64.din
--- cygwin64.din	25 Feb 2013 12:53:21 -0000	1.1.2.9
+++ cygwin64.din	4 Mar 2013 05:36:54 -0000
@@ -1348,7 +1348,7 @@ __wrap__ZdaPv NOSIGFE               # vo
 __wrap__ZdaPvRKSt9nothrow_t NOSIGFE # void operator delete[](void *p, const std::nothrow_t &nt) throw()
 __wrap__ZdlPv NOSIGFE               # void operator delete(void *p) throw()
 __wrap__ZdlPvRKSt9nothrow_t NOSIGFE # void operator delete(void *p, const std::nothrow_t &nt) throw()
-__wrap__Znaj NOSIGFE                # void *operator new[](std::size_t sz) throw (std::bad_alloc)
-__wrap__ZnajRKSt9nothrow_t NOSIGFE  # void *operator new[](std::size_t sz, const std::nothrow_t &nt) throw()
-__wrap__Znwj NOSIGFE                # void *operator new(std::size_t sz) throw (std::bad_alloc)
-__wrap__ZnwjRKSt9nothrow_t NOSIGFE  # void *operator new(std::size_t sz, const std::nothrow_t &nt) throw()
+__wrap__Znam NOSIGFE                # void *operator new[](std::size_t sz) throw (std::bad_alloc)
+__wrap__ZnamRKSt9nothrow_t NOSIGFE  # void *operator new[](std::size_t sz, const std::nothrow_t &nt) throw()
+__wrap__Znwm NOSIGFE                # void *operator new(std::size_t sz) throw (std::bad_alloc)
+__wrap__ZnwmRKSt9nothrow_t NOSIGFE  # void *operator new(std::size_t sz, const std::nothrow_t &nt) throw()
Index: libstdcxx_wrapper.cc
===================================================================
RCS file: /cvs/src/src/winsup/cygwin/libstdcxx_wrapper.cc,v
retrieving revision 1.3.8.1
diff -u -p -r1.3.8.1 libstdcxx_wrapper.cc
--- libstdcxx_wrapper.cc	18 Jan 2013 15:34:11 -0000	1.3.8.1
+++ libstdcxx_wrapper.cc	4 Mar 2013 05:36:54 -0000
@@ -22,19 +22,30 @@ details.  */
    around the standard C++ memory management operators; these are the wrappers,
    but we want the compiler to know they are the malloc operators and not have
    it think they're just any old function matching 'extern "C" _wrap_*'.  */
+#ifdef __x86_64__
+#define MANGLED_ZNWX			"__wrap__Znwm"
+#define MANGLED_ZNAX			"__wrap__Znam"
+#define MANGLED_ZNWX_NOTHROW_T		"__wrap__ZnwmRKSt9nothrow_t"
+#define MANGLED_ZNAX_NOTHROW_T		"__wrap__ZnamRKSt9nothrow_t"
+#else
+#define MANGLED_ZNWX			"___wrap__Znwj"
+#define MANGLED_ZNAX			"___wrap__Znaj"
+#define MANGLED_ZNWX_NOTHROW_T		"___wrap__ZnwjRKSt9nothrow_t"
+#define MANGLED_ZNAX_NOTHROW_T		"___wrap__ZnajRKSt9nothrow_t"
+#endif
 
 extern void *operator new(std::size_t sz) throw (std::bad_alloc)
-			__asm__ (_SYMSTR (__wrap__Znwj));
+			__asm__ (MANGLED_ZNWX);
 extern void *operator new[](std::size_t sz) throw (std::bad_alloc)
-			__asm__ (_SYMSTR (__wrap__Znaj));
+			__asm__ (MANGLED_ZNAX);
 extern void operator delete(void *p) throw()
 			__asm__ (_SYMSTR (__wrap__ZdlPv));
 extern void operator delete[](void *p) throw()
 			__asm__ (_SYMSTR (__wrap__ZdaPv));
 extern void *operator new(std::size_t sz, const std::nothrow_t &nt) throw()
-			__asm__ (_SYMSTR (__wrap__ZnwjRKSt9nothrow_t));
+			__asm__ (MANGLED_ZNWX_NOTHROW_T);
 extern void *operator new[](std::size_t sz, const std::nothrow_t &nt) throw()
-			__asm__ (_SYMSTR (__wrap__ZnajRKSt9nothrow_t));
+			__asm__ (MANGLED_ZNAX_NOTHROW_T);
 extern void operator delete(void *p, const std::nothrow_t &nt) throw()
 			__asm__ (_SYMSTR (__wrap__ZdlPvRKSt9nothrow_t));
 extern void operator delete[](void *p, const std::nothrow_t &nt) throw()

[-- Attachment #3: gcc48-ondee-64bit.patch --]
[-- Type: text/x-patch, Size: 2718 bytes --]

--- origsrc/gcc-4.8-20130224/gcc/config/i386/cygwin-w64.h	2013-03-03 23:36:49.242030600 -0600
+++ src/gcc-4.8-20130224/gcc/config/i386/cygwin-w64.h	2013-03-03 23:46:37.374669900 -0600
@@ -70,13 +70,14 @@ along with GCC; see the file COPYING3.
 
 /* To implement C++ function replacement we always wrap the cxx
    malloc-like operators.  See N2800 #17.6.4.6 [replacement.functions] */
+#undef CXX_WRAP_SPEC_LIST
 #define CXX_WRAP_SPEC_LIST " \
-  --wrap _Znwj \
-  --wrap _Znaj \
+  --wrap _Znwm \
+  --wrap _Znam \
   --wrap _ZdlPv \
   --wrap _ZdaPv \
-  --wrap _ZnwjRKSt9nothrow_t \
-  --wrap _ZnajRKSt9nothrow_t \
+  --wrap _ZnwmRKSt9nothrow_t \
+  --wrap _ZnamRKSt9nothrow_t \
   --wrap _ZdlPvRKSt9nothrow_t \
   --wrap _ZdaPvRKSt9nothrow_t \
 "
--- origsrc/gcc-4.8-20130224/gcc/configure	2013-02-01 14:26:24.000000000 -0600
+++ src/gcc-4.8-20130224/gcc/configure	2013-03-03 23:54:23.174312100 -0600
@@ -24261,7 +24261,7 @@ fi
 	# wrappers to aid in interposing and redirecting operators new, delete,
 	# etc., as per n2800 #17.6.4.6 [replacement.functions].  Check if we
 	# are configuring for a version of Cygwin that exports the wrappers.
-	if test x$host = x$target; then
+	if test x$host = x$target && test x$host_cpu = xi686; then
 	  ac_fn_c_check_func "$LINENO" "__wrap__Znaj" "ac_cv_func___wrap__Znaj"
 if test "x$ac_cv_func___wrap__Znaj" = x""yes; then :
   gcc_ac_cygwin_dll_wrappers=yes
@@ -24270,7 +24270,8 @@ else
 fi
 
 	else
-	  # Can't check presence of libc functions during cross-compile, so
+	  # Either we're compiling for x86_64-cygwin, which is new enough, or
+	  # we can't check presence of libc functions during cross-compile, so
 	  # we just have to assume we're building for an up-to-date target.
 	  gcc_ac_cygwin_dll_wrappers=yes
 	fi
--- origsrc/gcc-4.8-20130224/gcc/configure.ac	2013-02-01 14:26:24.000000000 -0600
+++ src/gcc-4.8-20130224/gcc/configure.ac	2013-03-03 23:53:37.503699900 -0600
@@ -3611,10 +3611,11 @@ changequote([,])dnl
 	# wrappers to aid in interposing and redirecting operators new, delete,
 	# etc., as per n2800 #17.6.4.6 [replacement.functions].  Check if we
 	# are configuring for a version of Cygwin that exports the wrappers.
-	if test x$host = x$target; then
+	if test x$host = x$target && test x$host_cpu = xi686; then
 	  AC_CHECK_FUNC([__wrap__Znaj],[gcc_ac_cygwin_dll_wrappers=yes],[gcc_ac_cygwin_dll_wrappers=no])
 	else
-	  # Can't check presence of libc functions during cross-compile, so
+	  # Either we're compiling for x86_64-cygwin, which is new enough, or
+	  # we can't check presence of libc functions during cross-compile, so
 	  # we just have to assume we're building for an up-to-date target.
 	  gcc_ac_cygwin_dll_wrappers=yes
 	fi

Re: [PATCH 64bit] Fix ONDEE for 64bit

[Corinna Vinschen]

On Mar  4 02:12, Yaakov wrote:
> Corinna,
> 
> More fun from our good friend, size_t:
> 
> Because operator new (in its various forms) takes a size_t argument, it
> is mangled differently on x86_64 above and beyond the common leading
> underscore issue.  Patches for winsup/cygwin and gcc (on top of your
> latest patch) attached.
> 
> 
> Yaakov

> 2013-03-04  Yaakov Selkowitz  <yselkowitz@...>
> 
> 	* cygwin64.din: Fix mangled operator new names for size_t==long.
> 	* libstdcxx_wrapper.cc: Ditto for x86_64.

That looks good, thanks for catching this problem!  Please apply the
Cygwin changes.  I'll rebuild new base packages including the gcc
patches soon.


Thanks again,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Re: [PATCH 64bit] Fix ONDEE for 64bit

[Yaakov]

[-- Attachment #1: Type: text/plain, Size: 477 bytes --]

On Mon, 4 Mar 2013 11:51:34 +0100, Corinna Vinschen wrote:
> That looks good, thanks for catching this problem!  Please apply the
> Cygwin changes.  I'll rebuild new base packages including the gcc
> patches soon.

BTW, at some point the attached patch will also need to be added for
4.8.  The libgcj ABI version changes with every GCC major.minor, and
this define seems to always be missed; a comment to this effect in
libjava/libtool-version probably wouldn't hurt.


Yaakov

[-- Attachment #2: gcc48-libgcj-version.patch --]
[-- Type: text/x-patch, Size: 1218 bytes --]

--- a/gcc/config/i386/cygwin.h	2013-01-10 14:38:27.000000000 -0600
+++ b/gcc/config/i386/cygwin.h	2013-03-04 00:18:04.989538700 -0600
@@ -137,5 +137,5 @@
 #define LIBGCC_SONAME "cyggcc_s" LIBGCC_EH_EXTN "-1.dll"
 
 /* We should find a way to not have to update this manually.  */
-#define LIBGCJ_SONAME "cyggcj" /*LIBGCC_EH_EXTN*/ "-13.dll"
+#define LIBGCJ_SONAME "cyggcj" /*LIBGCC_EH_EXTN*/ "-14.dll"
 
--- a/gcc/config/i386/cygwin-w64.h	2013-03-03 23:58:36.941826800 -0600
+++ b/gcc/config/i386/cygwin-w64.h	2013-03-04 00:18:00.309532200 -0600
@@ -155,4 +155,4 @@
 #define LIBGCC_SONAME "cyggcc_s" LIBGCC_EH_EXTN "-1.dll"
 
 /* We should find a way to not have to update this manually.  */
-#define LIBGCJ_SONAME "cyggcj" /*LIBGCC_EH_EXTN*/ "-13.dll"
+#define LIBGCJ_SONAME "cyggcj" /*LIBGCC_EH_EXTN*/ "-14.dll"
--- a/gcc/config/i386/mingw32.h	2013-01-10 14:38:27.000000000 -0600
+++ b/gcc/config/i386/mingw32.h	2013-03-04 05:35:13.791448500 -0600
@@ -245,4 +245,4 @@
 #define LIBGCC_SONAME "libgcc_s" LIBGCC_EH_EXTN "-1.dll"
 
 /* We should find a way to not have to update this manually.  */
-#define LIBGCJ_SONAME "libgcj" /*LIBGCC_EH_EXTN*/ "-13.dll"
+#define LIBGCJ_SONAME "libgcj" /*LIBGCC_EH_EXTN*/ "-14.dll"

Re: [PATCH 64bit] Fix ONDEE for 64bit

[Corinna Vinschen]

On Mar  4 05:39, Yaakov wrote:
> On Mon, 4 Mar 2013 11:51:34 +0100, Corinna Vinschen wrote:
> > That looks good, thanks for catching this problem!  Please apply the
> > Cygwin changes.  I'll rebuild new base packages including the gcc
> > patches soon.
> 
> BTW, at some point the attached patch will also need to be added for
> 4.8.  The libgcj ABI version changes with every GCC major.minor, and
> this define seems to always be missed; a comment to this effect in
> libjava/libtool-version probably wouldn't hurt.
> 
> 
> Yaakov

Thanks, but here's a question:  If the libgcj ABI version really changes
with every GCC major.minor release, wouldn't it then make sense to
change the libgcj DLL versioning scheme so it uses the GCC major.minor
number rather than an arbitrary version number?

In other words, why not cyggcj-4.8.dll?  This would allow easy
automation of Cygwin's LIBGCJ_SONAME, and everybody would know what
GCC version it's based on.


Corinna


-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Re: [PATCH 64bit] Fix ONDEE for 64bit

[Corinna Vinschen]

On Mar  4 14:15, Corinna Vinschen wrote:
> On Mar  4 05:39, Yaakov wrote:
> > On Mon, 4 Mar 2013 11:51:34 +0100, Corinna Vinschen wrote:
> > > That looks good, thanks for catching this problem!  Please apply the
> > > Cygwin changes.  I'll rebuild new base packages including the gcc
> > > patches soon.
> > 
> > BTW, at some point the attached patch will also need to be added for
> > 4.8.  The libgcj ABI version changes with every GCC major.minor, and
> > this define seems to always be missed; a comment to this effect in
> > libjava/libtool-version probably wouldn't hurt.
> > 
> > 
> > Yaakov
> 
> Thanks, but here's a question:  If the libgcj ABI version really changes
> with every GCC major.minor release, wouldn't it then make sense to
> change the libgcj DLL versioning scheme so it uses the GCC major.minor
> number rather than an arbitrary version number?
> 
> In other words, why not cyggcj-4.8.dll?  This would allow easy
> automation of Cygwin's LIBGCJ_SONAME, and everybody would know what
> GCC version it's based on.

Here's my version of the LIBGCJ_SONAME setting:

#ifndef BUILDING_GCC_MAJOR
#include "bversion.h"
#endif
#define ___cyg_mkstr(x) #x
#define __cyg_mkstr(x)  ___cyg_mkstr(x)
#define LIBGCJ_SONAME "cyggcj-" __cyg_mkstr (BUILDING_GCC_MAJOR) "." \
				__cyg_mkstr (BUILDING_GCC_MINOR) ".dll"


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Re: [PATCH 64bit] Fix ONDEE for 64bit

[Yaakov]

On Mon, 4 Mar 2013 15:40:22 +0100, Corinna Vinschen wrote:
> On Mar  4 14:15, Corinna Vinschen wrote:
> > Thanks, but here's a question:  If the libgcj ABI version really changes
> > with every GCC major.minor release, wouldn't it then make sense to
> > change the libgcj DLL versioning scheme so it uses the GCC major.minor
> > number rather than an arbitrary version number?
> > 
> > In other words, why not cyggcj-4.8.dll?  This would allow easy
> > automation of Cygwin's LIBGCJ_SONAME, and everybody would know what
> > GCC version it's based on.
> 
> Here's my version of the LIBGCJ_SONAME setting:
> 
> #ifndef BUILDING_GCC_MAJOR
> #include "bversion.h"
> #endif
> #define ___cyg_mkstr(x) #x
> #define __cyg_mkstr(x)  ___cyg_mkstr(x)
> #define LIBGCJ_SONAME "cyggcj-" __cyg_mkstr (BUILDING_GCC_MAJOR) "." \
> 				__cyg_mkstr (BUILDING_GCC_MINOR) ".dll"

I don't know if the version changes are a matter of policy or just how
it has happened, but in any case that's not the current versioning
scheme, nor is it how libtool libraries are usually versioned (and no,
libgnat is not built with libtool).  As long as this continues, the
following would work instead if you want to automate it:

#define LIBGCJ_SONAME "cyggcj-" __cyg_mkstr (BUILDING_GCC_MINOR+6) ".dll"

Also, you missed the #undef CXX_WRAP_SPEC_LIST before #define
CXX_WRAP_SPEC_LIST in cygwin-w64.h; this avoids a bunch of warnings
building GCC.


Yaakov

Re: [PATCH 64bit] Fix ONDEE for 64bit

[Corinna Vinschen]

On Mar  5 00:09, Yaakov wrote:
> On Mon, 4 Mar 2013 15:40:22 +0100, Corinna Vinschen wrote:
> > On Mar  4 14:15, Corinna Vinschen wrote:
> > > Thanks, but here's a question:  If the libgcj ABI version really changes
> > > with every GCC major.minor release, wouldn't it then make sense to
> > > change the libgcj DLL versioning scheme so it uses the GCC major.minor
> > > number rather than an arbitrary version number?
> > > 
> > > In other words, why not cyggcj-4.8.dll?  This would allow easy
> > > automation of Cygwin's LIBGCJ_SONAME, and everybody would know what
> > > GCC version it's based on.
> > 
> > Here's my version of the LIBGCJ_SONAME setting:
> > 
> > #ifndef BUILDING_GCC_MAJOR
> > #include "bversion.h"
> > #endif
> > #define ___cyg_mkstr(x) #x
> > #define __cyg_mkstr(x)  ___cyg_mkstr(x)
> > #define LIBGCJ_SONAME "cyggcj-" __cyg_mkstr (BUILDING_GCC_MAJOR) "." \
> > 				__cyg_mkstr (BUILDING_GCC_MINOR) ".dll"
> 
> I don't know if the version changes are a matter of policy or just how
> it has happened, but in any case that's not the current versioning
> scheme, nor is it how libtool libraries are usually versioned (and no,
> libgnat is not built with libtool).  As long as this continues, the
> following would work instead if you want to automate it:

Where exactly is the problem?  I thought *we* can define how the DLL is
called.  Is anything outside of the GCC toolchain expecting a specific
DLL name and relying on it?  I also don't understand the connection to
libgnat.  Does it load libgcj dynamically?  If not, why is it important
to libgnat how the libgcj DLL is called?!?

> #define LIBGCJ_SONAME "cyggcj-" __cyg_mkstr (BUILDING_GCC_MINOR+6) ".dll"
> 
> Also, you missed the #undef CXX_WRAP_SPEC_LIST before #define
> CXX_WRAP_SPEC_LIST in cygwin-w64.h; this avoids a bunch of warnings
> building GCC.

That wasn't in cygwin.h either.  I fix that.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Re: [PATCH 64bit] Fix ONDEE for 64bit

[Yaakov]

On Tue, 5 Mar 2013 09:49:50 +0100, Corinna Vinschen wrote:
> On Mar  5 00:09, Yaakov wrote:
> > I don't know if the version changes are a matter of policy or just how
> > it has happened, but in any case that's not the current versioning
> > scheme, nor is it how libtool libraries are usually versioned (and no,
> > libgnat is not built with libtool).  As long as this continues, the
> > following would work instead if you want to automate it:
> 
> Where exactly is the problem?  I thought *we* can define how the DLL is
> called.  Is anything outside of the GCC toolchain expecting a specific
> DLL name and relying on it? 

No, we don't control the DLL name; libjava/Makefile.am and
libjava/libtool-version determine the soname of libgcj based on
standard libtool naming and versioning practices.  Since GCC 3.2
(libgcj.so.3), there has been a consistent +1 version bump for each
major.minor release, hence the x+6 for the 4.x series
(for 4.8: cyggcj-14.dll, libgcj.so.14, etc.).

The define in cygwin*.h or mingw32.h is used in
libgcc/config/i386/cygming-crtbegin.c:__gcc_register_frame(), so it's
the define that needs to match the build system, not the other way
around.

> I also don't understand the connection to libgnat.

libgnat does use such an X.Y versioning scheme, but it does not use
libtool.  I just mentioned it to preempt what I thought was a likely
counterpoint; it has nothing to do with libgcj.


Yaakov

Re: [PATCH 64bit] Fix ONDEE for 64bit

[Corinna Vinschen]

On Mar  5 03:14, Yaakov wrote:
> On Tue, 5 Mar 2013 09:49:50 +0100, Corinna Vinschen wrote:
> > On Mar  5 00:09, Yaakov wrote:
> > > I don't know if the version changes are a matter of policy or just how
> > > it has happened, but in any case that's not the current versioning
> > > scheme, nor is it how libtool libraries are usually versioned (and no,
> > > libgnat is not built with libtool).  As long as this continues, the
> > > following would work instead if you want to automate it:
> > 
> > Where exactly is the problem?  I thought *we* can define how the DLL is
> > called.  Is anything outside of the GCC toolchain expecting a specific
> > DLL name and relying on it? 
> 
> No, we don't control the DLL name; libjava/Makefile.am and
> libjava/libtool-version determine the soname of libgcj based on
> standard libtool naming and versioning practices.  Since GCC 3.2
> (libgcj.so.3), there has been a consistent +1 version bump for each
> major.minor release, hence the x+6 for the 4.x series
> (for 4.8: cyggcj-14.dll, libgcj.so.14, etc.).
> 
> The define in cygwin*.h or mingw32.h is used in
> libgcc/config/i386/cygming-crtbegin.c:__gcc_register_frame(), so it's
> the define that needs to match the build system, not the other way
> around.

Sigh, ok.  I'll use your definition.  What do we do when gcc 5.0
is getting close?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Re: [PATCH 64bit] Fix ONDEE for 64bit

[Corinna Vinschen]

On Mar  5 10:30, Corinna Vinschen wrote:
> On Mar  5 03:14, Yaakov wrote:
> > On Tue, 5 Mar 2013 09:49:50 +0100, Corinna Vinschen wrote:
> > > On Mar  5 00:09, Yaakov wrote:
> > > > I don't know if the version changes are a matter of policy or just how
> > > > it has happened, but in any case that's not the current versioning
> > > > scheme, nor is it how libtool libraries are usually versioned (and no,
> > > > libgnat is not built with libtool).  As long as this continues, the
> > > > following would work instead if you want to automate it:
> > > 
> > > Where exactly is the problem?  I thought *we* can define how the DLL is
> > > called.  Is anything outside of the GCC toolchain expecting a specific
> > > DLL name and relying on it? 
> > 
> > No, we don't control the DLL name; libjava/Makefile.am and
> > libjava/libtool-version determine the soname of libgcj based on
> > standard libtool naming and versioning practices.  Since GCC 3.2
> > (libgcj.so.3), there has been a consistent +1 version bump for each
> > major.minor release, hence the x+6 for the 4.x series
> > (for 4.8: cyggcj-14.dll, libgcj.so.14, etc.).
> > 
> > The define in cygwin*.h or mingw32.h is used in
> > libgcc/config/i386/cygming-crtbegin.c:__gcc_register_frame(), so it's
> > the define that needs to match the build system, not the other way
> > around.
> 
> Sigh, ok.  I'll use your definition.  What do we do when gcc 5.0
> is getting close?

What about

#if BUILDING_GCC_MAJOR == 4
#define LIBGCJ_SONAME "cyggcj-" __cyg_mkstr (BUILDING_GCC_MINOR+6) ".dll"
#else
#error LIBGCJ_SONAME versioning scheme needs attention
#endif

for now?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Re: [PATCH 64bit] Fix ONDEE for 64bit

[Yaakov]

On Tue, 5 Mar 2013 10:30:09 +0100, Corinna Vinschen wrote:
> On Mar  5 03:14, Yaakov wrote:
> > No, we don't control the DLL name; libjava/Makefile.am and
> > libjava/libtool-version determine the soname of libgcj based on
> > standard libtool naming and versioning practices.  Since GCC 3.2
> > (libgcj.so.3), there has been a consistent +1 version bump for each
> > major.minor release, hence the x+6 for the 4.x series
> > (for 4.8: cyggcj-14.dll, libgcj.so.14, etc.).
> > 
> > The define in cygwin*.h or mingw32.h is used in
> > libgcc/config/i386/cygming-crtbegin.c:__gcc_register_frame(), so it's
> > the define that needs to match the build system, not the other way
> > around.
> 
> Sigh, ok.  I'll use your definition.  What do we do when gcc 5.0
> is getting close?

We can deal with it then, but at least we won't have to worry about
this for a while (as otherwise this seems to always be forgotten by
upstream).


Yaakov

Re: [PATCH 64bit] Fix ONDEE for 64bit

[Yaakov]

On Tue, 5 Mar 2013 10:38:50 +0100, Corinna Vinschen wrote:
> What about
> 
> #if BUILDING_GCC_MAJOR == 4
> #define LIBGCJ_SONAME "cyggcj-" __cyg_mkstr (BUILDING_GCC_MINOR+6) ".dll"
> #else
> #error LIBGCJ_SONAME versioning scheme needs attention
> #endif
> 
> for now?

Nope; this failed in boostrap stage 1 due to failed #include
<bversion.h>.

BTW, could you post your current gcc patch?


Yaakov

Re: [PATCH 64bit] Fix ONDEE for 64bit

[Corinna Vinschen]

On Mar 15 05:18, Yaakov wrote:
> On Tue, 5 Mar 2013 10:38:50 +0100, Corinna Vinschen wrote:
> > What about
> > 
> > #if BUILDING_GCC_MAJOR == 4
> > #define LIBGCJ_SONAME "cyggcj-" __cyg_mkstr (BUILDING_GCC_MINOR+6) ".dll"
> > #else
> > #error LIBGCJ_SONAME versioning scheme needs attention
> > #endif
> > 
> > for now?
> 
> Nope; this failed in boostrap stage 1 due to failed #include
> <bversion.h>.
> 
> BTW, could you post your current gcc patch?

It's the one from

ftp://ftp.cygwin.com/pub/cygwin/64bit/x86_64-pc-cygwin-gcc-20130305.patch

I didn't change anything in the toolchain since then.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Re: [PATCH 64bit] Fix ONDEE for 64bit

[Yaakov]

On Fri, 15 Mar 2013 11:26:55 +0100, Corinna Vinschen wrote:
> ftp://ftp.cygwin.com/pub/cygwin/64bit/x86_64-pc-cygwin-gcc-20130305.patch
> 
> I didn't change anything in the toolchain since then.

This hunk doesn't look right (gcc/config/i386/i386.c):

>        if (TARGET_64BIT && DEFAULT_ABI == MS_ABI)
> -       ix86_cmodel = CM_SMALL_PIC, flag_pic = 1;
> +#ifdef TARGET_CYGWIN64
> +       ix86_cmodel = CM_MEDIUM_PIC, flag_pic = 1;
> +#else
> +       ix86_cmodel = CM_MEDIUM_PIC, flag_pic = 1;
> +#endif

It doesn't affect us right now, but this needs to be fixed before
pushing upstream.

Also, in libstdc++-v3/crossconfig.m4:

> +  *-cygwin*)
> +    GLIBCXX_CHECK_COMPILER_FEATURES
> +    GLIBCXX_CHECK_LINKER_FEATURES
> +    GLIBCXX_CHECK_MATH_SUPPORT
> +    GLIBCXX_CHECK_STDLIB_SUPPORT
> +    ;;

I think cygwin should be added to the preceding linux|gnu|k*bsd-gnu
case, as we also have /dev/random, pthreads, and iconv.

BTW, the good news is that I was able to build cygwin-64bit-branch and
gcc (3-stage bootstrap with C/C++) natively on x86_64, albeit with
-j1, so we're officially at the point of self-hosting.  Hopefully your
latest patches will fix parallel make, but that will have to wait until
next week.


Yaakov

Re: [PATCH 64bit] Fix ONDEE for 64bit

[Corinna Vinschen]

On Mar 15 16:56, Yaakov wrote:
> On Fri, 15 Mar 2013 11:26:55 +0100, Corinna Vinschen wrote:
> > ftp://ftp.cygwin.com/pub/cygwin/64bit/x86_64-pc-cygwin-gcc-20130305.patch
> > 
> > I didn't change anything in the toolchain since then.
> 
> This hunk doesn't look right (gcc/config/i386/i386.c):
> 
> >        if (TARGET_64BIT && DEFAULT_ABI == MS_ABI)
> > -       ix86_cmodel = CM_SMALL_PIC, flag_pic = 1;
> > +#ifdef TARGET_CYGWIN64
> > +       ix86_cmodel = CM_MEDIUM_PIC, flag_pic = 1;
> > +#else
> > +       ix86_cmodel = CM_MEDIUM_PIC, flag_pic = 1;
> > +#endif
> 
> It doesn't affect us right now, but this needs to be fixed before
> pushing upstream.

No, this is right at the moment, according to Kai.  Cygwin is supposed
to use the medium code model by default anyway, to support the notion
not having to add "dllimport" to any variable imported from a DLL.  And
the second case is a "reminder to self" from Kai that he's planning to
use the medium model by default on Mingw64 as well at one point.

> Also, in libstdc++-v3/crossconfig.m4:
> 
> > +  *-cygwin*)
> > +    GLIBCXX_CHECK_COMPILER_FEATURES
> > +    GLIBCXX_CHECK_LINKER_FEATURES
> > +    GLIBCXX_CHECK_MATH_SUPPORT
> > +    GLIBCXX_CHECK_STDLIB_SUPPORT
> > +    ;;
> 
> I think cygwin should be added to the preceding linux|gnu|k*bsd-gnu
> case, as we also have /dev/random, pthreads, and iconv.

Yeah, this sounds like the right thing to do.  Thanks for the reminder.
I can build a new linux toolchain next week, and I suppose you did
build your native gcc toolchain with these changes already?

> BTW, the good news is that I was able to build cygwin-64bit-branch and
> gcc (3-stage bootstrap with C/C++) natively on x86_64, albeit with
> -j1, so we're officially at the point of self-hosting.  Hopefully your
> latest patches will fix parallel make, but that will have to wait until
> next week.

Yes, it does, but the price is too high.  It's still a really puzzeling
problem and the patch, even though it appeared to fix parallel makes,
is apparently only covering the real, still undiscovered problem.

The patch only moved the place in the code at which the pseudo relocator
is called in the child after fork.  In the old location, everything
appears to work fine, except for those weird, random crashes in parallel
makes.  In the new location, the parallel makes work fine, but then
autoreconf hangs in bash.

This is really, really frustrating.  I hope we can fix this next week,
but right now I need a weekend off to get my head clear.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Re: [PATCH 64bit] Fix ONDEE for 64bit

[Yaakov]

On Sat, 16 Mar 2013 11:45:15 +0100, Corinna Vinschen wrote:
> > Also, in libstdc++-v3/crossconfig.m4:
> > 
> > > +  *-cygwin*)
> > > +    GLIBCXX_CHECK_COMPILER_FEATURES
> > > +    GLIBCXX_CHECK_LINKER_FEATURES
> > > +    GLIBCXX_CHECK_MATH_SUPPORT
> > > +    GLIBCXX_CHECK_STDLIB_SUPPORT
> > > +    ;;
> > 
> > I think cygwin should be added to the preceding linux|gnu|k*bsd-gnu
> > case, as we also have /dev/random, pthreads, and iconv.
> 
> Yeah, this sounds like the right thing to do.  Thanks for the reminder.
> I can build a new linux toolchain next week, and I suppose you did
> build your native gcc toolchain with these changes already?

I also discovered two more gcc macros which were missing updates for
x86_64-cygwin.  I have added those patches, and incorporated your x86_64
patches into mine, into a 4.8 branch of my gcc port:

http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/gcc;a=shortlog;h=refs/heads/4.8

I am building native and 32-to-64 compilers with this patchset now.

> > BTW, the good news is that I was able to build cygwin-64bit-branch and
> > gcc (3-stage bootstrap with C/C++) natively on x86_64, albeit with
> > -j1, so we're officially at the point of self-hosting.  Hopefully your
> > latest patches will fix parallel make, but that will have to wait until
> > next week.
> 
> Yes, it does, but the price is too high.  It's still a really puzzeling
> problem and the patch, even though it appeared to fix parallel makes,
> is apparently only covering the real, still undiscovered problem.
> 
> The patch only moved the place in the code at which the pseudo relocator
> is called in the child after fork.  In the old location, everything
> appears to work fine, except for those weird, random crashes in parallel
> makes.  In the new location, the parallel makes work fine, but then
> autoreconf hangs in bash.

So I noticed; for now, I've reverted to -5 and MAKEOPTS=-j1.

> This is really, really frustrating.  I hope we can fix this next week,
> but right now I need a weekend off to get my head clear.

Well, with the sourceware upgrade, we've got a few days before we can
proceed much further either way.


Yaakov

Re: [PATCH 64bit] Fix ONDEE for 64bit

[Yaakov]

On Sun, 17 Mar 2013 04:18:25 -0500, Yaakov (Cygwin/X) wrote:
> I also discovered two more gcc macros which were missing updates for
> x86_64-cygwin.  I have added those patches, and incorporated your x86_64
> patches into mine, into a 4.8 branch of my gcc port:
> 
> http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/gcc;a=shortlog;h=refs/heads/4.8
> 
> I am building native and 32-to-64 compilers with this patchset now.

libgcj needs some work, and gnat will have to wait until I can get a
native gnat 4.8, but the current tip of this branch builds successfully
for C/C++/Fortran/ObjC/ObjC++.


Yaakov

Re: [PATCH 64bit] Fix ONDEE for 64bit

[Corinna Vinschen]

On Mar 17 18:49, Yaakov wrote:
> On Sun, 17 Mar 2013 04:18:25 -0500, Yaakov (Cygwin/X) wrote:
> > I also discovered two more gcc macros which were missing updates for
> > x86_64-cygwin.  I have added those patches, and incorporated your x86_64
> > patches into mine, into a 4.8 branch of my gcc port:
> > 
> > http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/gcc;a=shortlog;h=refs/heads/4.8
> > 
> > I am building native and 32-to-64 compilers with this patchset now.
> 
> libgcj needs some work, and gnat will have to wait until I can get a
> native gnat 4.8, but the current tip of this branch builds successfully
> for C/C++/Fortran/ObjC/ObjC++.

Do you have a full diff relative to GCC HEAD?


Thanks.
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Re: [PATCH 64bit] Fix ONDEE for 64bit

[Yaakov]

On Mon, 18 Mar 2013 11:09:24 +0100, Corinna Vinschen wrote:
> On Mar 17 18:49, Yaakov wrote:
> > On Sun, 17 Mar 2013 04:18:25 -0500, Yaakov (Cygwin/X) wrote:
> > > I also discovered two more gcc macros which were missing updates for
> > > x86_64-cygwin.  I have added those patches, and incorporated your x86_64
> > > patches into mine, into a 4.8 branch of my gcc port:
> > > 
> > > http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/gcc;a=shortlog;h=refs/heads/4.8
> > > 
> > > I am building native and 32-to-64 compilers with this patchset now.
> > 
> > libgcj needs some work, and gnat will have to wait until I can get a
> > native gnat 4.8, but the current tip of this branch builds successfully
> > for C/C++/Fortran/ObjC/ObjC++.
> 
> Do you have a full diff relative to GCC HEAD?

I've been focusing on 4.8 right now, so what I have is in the
aforementioned branch (which I updated just yesterday).  Working on
upstream HEAD will have to wait a few weeks.


Yaakov

Re: [PATCH 64bit] Fix ONDEE for 64bit

[Corinna Vinschen]

On Mar 22 02:23, Yaakov wrote:
> On Mon, 18 Mar 2013 11:09:24 +0100, Corinna Vinschen wrote:
> > On Mar 17 18:49, Yaakov wrote:
> > > On Sun, 17 Mar 2013 04:18:25 -0500, Yaakov (Cygwin/X) wrote:
> > > > I also discovered two more gcc macros which were missing updates for
> > > > x86_64-cygwin.  I have added those patches, and incorporated your x86_64
> > > > patches into mine, into a 4.8 branch of my gcc port:
> > > > 
> > > > http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/gcc;a=shortlog;h=refs/heads/4.8
> > > > 
> > > > I am building native and 32-to-64 compilers with this patchset now.
> > > 
> > > libgcj needs some work, and gnat will have to wait until I can get a
> > > native gnat 4.8, but the current tip of this branch builds successfully
> > > for C/C++/Fortran/ObjC/ObjC++.
> > 
> > Do you have a full diff relative to GCC HEAD?
> 
> I've been focusing on 4.8 right now, so what I have is in the
> aforementioned branch (which I updated just yesterday).  Working on
> upstream HEAD will have to wait a few weeks.

Ok, cool.

Thanks for all your hard work to get the test distro into a working
state!


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat