search for: go_write_export_data

...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...

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

...ery (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 yo...

Hi! 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