G'day Tristan,
I finally found some time to get GHDL to build under cygwin.
Pretty much everything worked for me except for processes that do not have a
sensitive list.
I experienced an exception in the cygwin1.dll which I think is attributed to
the CreateFiber call not initialising cygwin's TLS memory block.
Using the teststack.c application I could get the fiber implementation to pass
provided no cygwin functions were called in one of the created threads. Adding
a printf in each thread resulted in the same exception.
Anyway I tried investigating what needed to be done but it all looked to hard.
So I've gone back to the pthread implmenation under cygwin with the following
patch. For some reason cygwin on my box at least is doing something strange
with the mutex, it looks to be creating the mutex as a PTHREAD_MUTEX_TIMED_NP
if NULL is passed in for the type. I was getting an error code indicating that
access was denied to the mutex. This doesn't follow the mutex documentation.
Anyway with this patch ghdl it all seems to work based on comparison testing
between the the cygwin version and your windows build.
I haven't traced how you do the windows build but I'm assuming you're using
mingw and the changes I've done to the makefile.inc for the grt wont affect
anything.
For anyone interested in building under cygwin:
I used the latest gcc / gcc-ada binaries to build gcc / gcc-ada 4.1.1 from
source.
Installed them.
Rebuilt gcc / gcc-ada with the new 4.1.1 binaries. (I did try to bootstrap the
build but ada failed in bootstrap for me.)
Installed the new bianries.
I then added the ghdl source to the gcc-4.1.1 tree and built gcc / gcc-ada /
ghdl with the latest 4.1.1 toolchain.
I was also able to follow Tristan's instructions to build a debug version of
ghdl and that worked without any issue as well.
I've also start to see if I could get gcov to work. Unfortunately gcov core
dumps on most files that are generated. The exe's all build and run fine. Just
gcov crashes when generating the human readable output. Anyone used this
recently?
Arnim Läuger documenation for this was with gcc 3.3.3 so I'm unsure at the
moment if this is a cygwin issue or a gcc 4.1.1 issue.
Regards
Phil
Index: translate/grt/config/pthread.c
===================================================================
--- translate/grt/config/pthread.c (revision 61)
+++ translate/grt/config/pthread.c (working copy)
@@ -28,6 +28,7 @@
#include <stdlib.h>
#include <stdio.h>
#include <setjmp.h>
+#include <assert.h>
//#define INFO printf
#define INFO (void)
@@ -37,6 +38,9 @@
typedef struct
{ pthread_t thread; // stack's thread
pthread_mutex_t mutex; // mutex to suspend/resume thread
+#if defined(__CYGWIN__)
+ pthread_mutexattr_t mxAttr;
+#endif
void (*Func)(void*); // stack's FUNC
void* Arg; // ARG passed to FUNC
} Stack_Type_t, *Stack_Type;
@@ -54,10 +58,16 @@
{ INFO("grt_stack_init\n");
INFO(" main_stack_context=0x%08x\n", &main_stack_context);
- pthread_mutex_init(&(main_stack_context.mutex), NULL);
+#if defined(__CYGWIN__)
+ assert(pthread_mutexattr_init(&(main_stack_context.mxAttr)) == 0);
+ assert(pthread_mutexattr_settype(&(main_stack_context.mxAttr),
PTHREAD_MUTEX_DEFAULT) == 0);
+ assert(pthread_mutex_init(&(main_stack_context.mutex),
&(main_stack_context.mxAttr)) == 0);
+#else
+ assert(pthread_mutex_init(&(main_stack_context.mutex), NULL) == 0);
+#endif
// lock the mutex, as we are currently running
- pthread_mutex_lock(&(main_stack_context.mutex));
+ assert(pthread_mutex_lock(&(main_stack_context.mutex)) == 0);
current = &main_stack_context;
@@ -105,10 +115,16 @@
newStack->Arg= Arg;
// create mutex
- pthread_mutex_init(&(newStack->mutex), NULL);
-
+#if defined(__CYGWIN__)
+ assert(pthread_mutexattr_init(&(newStack->mxAttr)) == 0);
+ assert(pthread_mutexattr_settype(&(newStack->mxAttr),
PTHREAD_MUTEX_DEFAULT) == 0);
+ assert(pthread_mutex_init(&(newStack->mutex), &(newStack->mxAttr)) ==
0);
+#else
+ assert(pthread_mutex_init(&(newStack->mutex), NULL) == 0);
+#endif
+
// block the mutex, so that thread will blocked in grt_stack_loop
- pthread_mutex_lock(&(newStack->mutex));
+ assert(pthread_mutex_lock(&(newStack->mutex)) == 0);
INFO(" newStack=0x%08x\n", newStack);
@@ -135,12 +151,12 @@
// unlock 'To' mutex. this will make the other thread either
// - starts for first time in grt_stack_loop
// - resumes at lock below
- pthread_mutex_unlock(&(To->mutex));
+ assert(pthread_mutex_unlock(&(To->mutex)) == 0);
// block until 'From' mutex becomes available again
// as we are running, our mutex is locked and we block here
// when stacks are switched, with above unlock, we may proceed
- pthread_mutex_lock(&(From->mutex));
+ assert(pthread_mutex_lock(&(From->mutex)) == 0);
if (From == &main_stack_context && need_longjmp != 0)
longjmp (run_env, need_longjmp);
Index: translate/grt/Makefile.inc
===================================================================
--- translate/grt/Makefile.inc (revision 61)
+++ translate/grt/Makefile.inc (working copy)
@@ -73,7 +73,8 @@
GRT_TARGET_OBJS=win32.o clock.o
endif
ifeq ($(filter-out i%86 cygwin,$(arch) $(osys)),)
- GRT_TARGET_OBJS=win32.o clock.o
+ GRT_TARGET_OBJS=pthread.o clock.o
+ GRT_EXTRA_LIB=-lpthread -ldl -lm
endif
# Fall-back: use a generic implementation based on pthreads.
ifndef GRT_TARGET_OBJS
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: Tuesday, 5 September 2006 9:27 PM
To: GHDL discuss list
Subject: RE: [Ghdl-discuss] ghdl & windows
Quoting Phil Reid <[EMAIL PROTECTED]>:
> I'd be interested in some instructions on how to build ghdl under
> cygwin or pure windows.
For cygwin: You may try to search the web.
For pure windows: use the svn repository, build the .zip under linux and then
work under Windows (Yeah not easy !)
> I might be inspired to add some functionality (eg ability to select
> which signals to record).
Tristan.
_______________________________________________
Ghdl-discuss mailing list
[email protected]
https://mail.gna.org/listinfo/ghdl-discuss
_______________________________________________
Ghdl-discuss mailing list
[email protected]
https://mail.gna.org/listinfo/ghdl-discuss
