Code: Select all
/*
This is a stub used to create the symbols __bss_start and _end in a Mach-O object file.
Thoses are needed by the GC, and should point to the start and end of the bss section.
We reach this goal by linking this file last (putting _end at the end...), and using an
order file (order.def) to move __bss_start at the start of bss.
TODO: Some pragma to do it inline ?
*/
char __bss_start = 0;
char _end = 0;If there were we would have used it.p-i- wrote:Thanks for the explanations.
I can see this is awkward in terms of creating a generic build.
My goal is still to be able to drop a wodge of C code into some C/C++project (on unspecified platform) and instantly have embedded Python.
I think this could eventually go in a /generic/ folder
But this issue seems to be a clear case of requiring separate machinery for non-gcc e.g. clang.
Is there any way around this?
BSS is where C stores uninitialized (or initialzed to zero) global data. DATA is where C stores initialized global data.p-i- wrote:I'm getting a little confused about Python-land vs C-land. This BSS_START to _end -- is this the space in which our C program stores its static data? Or is it where the embedded Python runtime stores it's static data? Or both?
That's essentially what's happening when you throw the contents of BSS at the garbage collector. In the more generic case (embedding micropython inside another program), the other program will have its own heap, and that heap may contain pointers to python objects. The GC needs to know about those, but it doesn't know where to look to find them.p-i- wrote:Would it be possible to get round this problem by (as dhylands suggested on IRC) manually keeping track of every external (C-land reference to a Python object), and then just throwing an array of these memory locations into the garbage collector?
It's for the GC managed heap. If C code happens to allocate from it, then it covers that case as well. In MicroPython, there is no heap, other than the GC managed one, so all heap allocations come from the GC managed heap. For example:p-i- wrote:Also, this garbage collector -- it is just for the Python runtime, yes? Or is it also being used to clean up unused C memory?
I know you're not looking for it, but using a library fixes most of your problems. Moreover a library has it's own bss section (as far as I know) which answers your other question: normally only the static data from micropython needs to be scanned, it's of no use to the gc to scan sections of the whole program.p-i- wrote:Is there any way around this?
You would indeed need something like that. Part of this can be done automatically: create a micropython list and store it in the global micropython dict. Everything stored in the list will then get scanned by the gc so you only have to take care of putting your stuff in the list. Also make sure if you create a custom class and add functions to it (locals_dict member of the type object) to store that in the list as well otherwise it might get sweepd, I've had problems with that myselfWould it be possible to get round this problem by (as dhylands suggested on IRC) manually keeping track of every external (C-land reference to a Python object), and then just throwing an array of these memory locations into the garbage collector?
That would be nice but could also lead to tons of #ifdef all over the place. Not sure how much work reference counting requires.The idea might be to have a preprocessor flag that determines whether the GC uses the current "mark and sweep" or reference counting.
