This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: gccgo branch and darwin
On Fri, Nov 19, 2010 at 12:16:43PM -0800, Ian Lance Taylor wrote:
> Jack Howarth <howarth@bromo.med.uc.edu> writes:
>
> > The current gccgo branch (at r166931) fails to bootstrap on x86_64-apple-darwin10
> > using...
>
> Thanks for trying it. If you fix that problem, you're going to have
> other problems too.
>
> Specifically, I know that it's going to fail to create a .go_export
> section because the assembler is going to complain about bad syntax.
> Although one nice consequence of my simple_object work is that if we can
> get the section created correctly we might be able to read it at import
> time without further work.
>
> I don't know what will fail after that problem is fixed.
>
> I would certainly like gccgo to work on Darwin, and, for that matter
> anywhere other than GNU/Linux and RTEMS. But I can not commit to fixing
> anything other than GNU/Linux myself. I'm going to have to rely on
> other people for that. Sorry to be blunt, but I'm just one person, and
> there is no feasible alternative.
>
> I am not going to let this issue hold up the merge. Go will not be
> enabled by default, so the merge will not break any builds which do not
> explicitly enable Go.
>
>
> > ../../../gccgo/libgo/runtime/go-go.c:379:29: error: âSIGRTMINâ undeclared (first use in this function)
>
> The issue here is that in the current implementation the garbage
> collector requires two signals: one to tell a thread that a garbage
> collection is starting and one to tell a thread that it is complete.
> The current code does this:
>
> #define GO_SIG_START (SIGRTMIN + 1)
> #define GO_SIG_STOP (SIGRTMIN + 2)
>
> because I can be reasonably confident that no Go program expects to do
> anything with those signals (a Go program which links with a C library
> which uses those signals in some other way is going to fail, yes;
> suggestions welcome).
>
> I'm a little surprised to hear that Darwin doesn't have real time
> signals. I think they've been in POSIX for about 15 years now. Perhaps
> some preprocessor define makes them available? If not, then somebody
> familiar with Darwin is going to have to pick two other signals for
> Darwin. The Go code does not actually need the special properties of
> real-time signals; any unused signal should suffice.
Ian,
Actually, darwin doesn't use the boehm-gc/pthread_stop_world.c containing
the SIGRTMIN code. There is an entirely separate boehm-gc/darwin_stop_world.c
for the thread handling on darwin. While boehm-gc/pthread_stop_world.c is
compiled on darwin, the code in it is skipped because of the...
#if defined(GC_PTHREADS) && !defined(GC_SOLARIS_THREADS) \
&& !defined(GC_WIN32_THREADS) && !defined(GC_DARWIN_THREADS)
...wrapper.
Jack
>
> Ian