search for: go_export

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

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

...chinery (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_DE...

...is might interact with ELF or COFF. > > - Daniel I don't know of any ELF implementation that currently supports this in general, but adding it should't be too hard. Go does automatic linking, but it now has its own object file format that handles it. gccgo for ELF seems to produce .go_export sections and <package>..import symbols which are both specific to Go. - Michael Spencer

Hi all, We plan to add some auto-linking support for Mach-O, and need a scheme for encoding this information in the LLVM IR. We would like the same scheme to be able to support Microsoft's #pragma comment(lib,...) and #pragma comment(library, ...) features eventually. The current proposal is as follows: -- #1. Extend module-level metadata flags (llvm.module.flags) to support two new