llvm dev - Aug 2011 - [LLVMdev] Segmented Stacks: Pre-midterm work

> 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);
> }
:-(

Fixing things like this was fairly painful in the past. It is sad to see new
cases showing up.
> 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.
Cheers,
Rafael

As far as I can see (after hand-tweaking the assembly generated for a
simple example), there is no problem with the calling
convention. Also, go_write_export_data only seems to generate to some
sort of debug information (which does not look like DWARF).

However, there seems to be some problem with how LLVM handles
trampolines -- I'm currently trying find out what exactly the problem
is.

-- 
Sanjoy Das
http://playingwithpointers.com

2011/8/17 Sanjoy Das <sanjoy at
playingwithpointers.com>:
> As far as I can see (after hand-tweaking the assembly generated for a
> simple example), there is no problem with the calling
> convention. Also, go_write_export_data only seems to generate to some
> sort of debug information (which does not look like DWARF).
It's not exactly debug info. It's export info. Go doesn't have
header
files, but the compiler needs some way of discovering what functions,
types, variables, and constants a package defines when it is imported.
It does this by parsing the package's export information.

- Evan