Implement buildmode=c-archive

[hectorchu]

This is - not fully polished - but is opened here in the hope that suggestions and improvements can be made. Fixes #254

It does work - pretty well actually - for Xtensa. There, a component can be made with a simple:

idf_component_register()

add_prebuilt_library(foo "foo.a")

target_link_libraries(${COMPONENT_LIB} INTERFACE foo)

[hectorchu]

Minimum app.c supporting code:

#include <stdlib.h>

void tinygo_init(void *p, size_t n, void *bss, void *bss_end, void *sp);
int _globals_start, _globals_end, _stack_top;
extern uint8_t _bss_start, _bss_end;

void app_main(void)
{
    int heap = 200000;
    tinygo_init(malloc(heap), heap, &_bss_start, &_bss_end, &heap);
    // ready to call CGo exported functions
}

[aykevl]

In my opinion this looks a little bit too specific to one particular platform at the moment (Xtensa), while there are many other possible platforms. For example, Linux. The design will likely need significant changes to work more universally.

[hectorchu]

In my opinion this looks a little bit too specific to one particular platform at the moment (Xtensa), while there are many other possible platforms. For example, Linux. The design will likely need significant changes to work more universally.

It's more universal than you might think, though. I first developed c-archive to build a static lib for macOS, I confirmed it worked by linking that .a to a test.c program. My real target is esp32 which is why there's xtensa-specific workarounds in there. But for Linux I think it would mostly "just-work".

[aykevl]

In my opinion this is a bit too messy to really review and form an opinion on. See the comments below.

Some things I definitely want to see improved before reviewing again:

• It needs tests. There currently are none. Without tests, it will break eventually. In particular, it needs tests to show CGo still works correctly (or alternatively CGo support needs to be disabled - this might be difficult since we rely on CGo for a bunch of features).
• It should not build the C library and should not add C header files to the C include path, since in that case we'll be mixing two C libraries which will break in "interesting" ways.

[aykevl]

"description" is for humans, not computers. Don't use it.

[hectorchu]

I do realize this, but there was no other way to tell if the .bc file was a product of a .S. You see, some of those .bc files are actually .o files, but with a .bc extension. So I can't just filter by .bc extension.

[hectorchu]

In other words there is a separate bug to do with how the dependency results are named.

[aykevl]

Please make this a bit more generic.

[hectorchu]

I tried running this code block for macOS target and the linker failed, can't remember the error message, but that's why its scoped to xtensa.

[hectorchu]

Oops sorry, got this mixed up with the second xtensa block. This one, is all about putting functions into their own sections (basically doing -ffunction-sections - generates a separate ELF section for each function in the source file). The reason this is needed is because the literal sections need to be as close to the code referring to them as possible - or else you get l32r dangerous relocation linker errors from esp-idf (specifically literal target out of range).

[aykevl]

Why is this needed? It is somewhat unexpected, so please add a comment what it does and why it is needed.

[hectorchu]

These atomic and sync functions are also defined in esp-idf. So this fix avoids multiple definitions.

[aykevl]

This needs documentation.

[aykevl]

At one point you limit it to Xtensa, but here you modify macOS related code.

[hectorchu]

This "fix" is because, when I was developing this feature for macOS target, it assumes boehm and task_thread.c must be linked even if gc=conservative and scheduler=none. Probably the same errors would happen when just building regular binaries.

[hectorchu]

So probably I'd be happy to remove these changes - it's a separate issue.

[hectorchu]

It should not build the C library and should not add C header files to the C include path, since in that case we'll be mixing two C libraries which will break in "interesting" ways.

About this, the reason I still build the libc but don't link it, is because my CGo modules won't compile unless it can find the header files. And in the case of xtensa, the libc is picolibc, which is also available in esp-idf. So the same libc can be used.