[LLVMdev] Segmented Stacks: Pre-midterm work

[Duncan Sands]

Hi Sanjoy,

> I've been working on coroutines for some time, and it seems you were
> right - it makes much more sense to have regular C (and assembly) code
> for handling coroutines. For instance, I'd otherwise would have to
> make an assumption about the threading model the platform has (or
> assume there are no threads at all, which prevents me from allowing
> goroutine like ("run parallel till you need to write to a channel")
> behavior).
>
> Right now I'm sort-of dogfooding my work by trying to get Go running
> on dragonegg. I've discovered some small issues already (for instance
> I need to save R10 somewhere when compiling a function with a nest
> parameter). I'll send a revised set of patches within sometime this
> week, addressing all such issues I can find.
>
> That apart, about getting Go to work with dragonegg:
>
> 1. Does it sound viable?
> 2. What things do I need to keep in mind?
>
> Currently, I'm passing `-fplugin=./dragonegg.so' to gccgo and have
> edited dragonegg to enable segmented stacks when it detects the
> language is "GNU Go". This seems to do what I expect (saving the fact
> the binaries throw a mysterious SIGILL :) ).

thanks for working on this!  As far as I know, split stacks are the only thing
special to GCC Go, otherwise the generic GCC infrastructure was enough.  If that
is true then you shouldn't need to do more than what you described above, except
for poking at things until they work of course!  The usual source of trouble is
when front-ends trying to write things directly to the assembler file, bypassing
the generic machinery (and thereby bypassing dragonegg).  In order to support
LTO front-ends shouldn't do this anymore, but some (eg: java) still do.  I had
a look at the GO front-end and I see this suspicious code:

/* This is called by the Go frontend proper to add data to the
    .go_export section.  */

void
go_write_export_data (const char *bytes, unsigned int size)
{
   static section* sec;

   if (sec == NULL)
     {
       gcc_assert (targetm_common.have_named_sections);
       sec = get_section (".go_export", SECTION_DEBUG, NULL);
     }

   switch_to_section (sec);
   assemble_string (bytes, size);
}

So you might want to check if copying .go_export sections from the GCC compiled
assembler file into the dragonegg compile assembler files suddenly causes Go
programs to start working.

Ciao, Duncan.