07:59 <_franck_> st-gourichon-fid what is annoying you with this change in the linker script ?

11:51 <st-gourichon-fid> _florent_, thanks for asking! In our design, another microcontroller runs code compiled with another SDK and linker script, and little flexibility without modifying the SDK itself, which contains the linker script used. So far we could progress without modifying the SDK.

11:56 <st-gourichon-fid> I considered alternatives, like: before compilation, generating a C-source-level array listing all symbols. Fully scripted "build in one step" of course. We can also run a modified SDK from now on. ¯\_(ツ)_/¯

11:57 <st-gourichon-fid> "all symbols" -> providing the same C-runtime-level array without linker script trick.

13:44 <_franck_> st-gourichon-fid without the linker section and the KEEP attribute, you may have to find a trick to keep cmd functions in the object file (not beeing stripped away)

13:45 <_franck_> and by the way there is _franck_ and _florent_ :)

14:43 <zyp> _franck_, listing them in an array would reference them and keep them from being garbage collected, no tricks needed

14:44 <zyp> st-gourichon-fid, are you saying that you are building the litex bios against the SDK for another microcontroller? I'm not sure I understand exactly what you're trying to do

15:14 <st-gourichon-fid> _franck_, thanks for your answer. And yes, I was bitten by the IRC client autocompletion. :-p

15:15 <st-gourichon-fid> zyp, the other microcontroller is an external chip that can access the wishbone bus, so it can be very handy to run the bios prompt on that chip.

15:33 <zyp> makes sense

15:33 <zyp> at least if you're using peripherals that the bios runs initialization for

15:48 <st-gourichon-fid> Running our own interactive commands (with readline) is an appreciated luxury.

16:19 <_franck_> zyp you're right, I've misread "generating a C-source-level array listing all symbols". I was thinking at something that would have emulated the linker section.