Using Perlmonks as a rubber duck ... ;-)

All that I need is a way to tell the linker to stop cleaning up my precious section. Shouldn't be that hard, right?

It isn't that hard. Just tell the linker to KEEP records in my section. Exactly as it is done by default for constructor functions. D'oh!

Now my plan works.

Alexander

Now guess what happens: You forget to add your New_Init() and New_Run() to main(), and suddenly, the system behaves very strange. In fact, it is number one on our debugging check list. Number two is wrong order of the init functions. Also, all that hand-written stuff takes a lot of time when you set up a new project.

One idea is to have a single config file in some easy to understand format and have Perl write the .c and .h code for this initialization and loop run code from that.

You have to modify your make file to accommodate that Perl step. In general there is no problem with having a program write another program (Larry Wall says that these are the happiest programs of all).

Your question sounds more like a C question than a Perl question.

Yes, that's why I marked my posting as off-topic.

One idea is to have a single config file in some easy to understand format and have Perl write the .c and .h code for this initialization and loop run code from that.

Yes, that would be possible.

I've considered generating the entire main.c from the module sources using a perl script. But we usually put some application-specific code into main that does not fit elsewhere, so a generated main.c is not acceptable, and so I gave up that idea.

But you are right, I could get away by simply reading all module file names from the AS project file, extracting XXX_Init() functions from the modules, and generate an auxillary file that basically just contains an array of pointers to init functions. That would work without messing with the linker, and I wouldn't even need a config file. We already do something similar to assemble a version number.

I could even go one step back and assemble two arrays, one for init functions, one for run functions. That way, our software would still have two distinct global phases, one init, one run, and except for making all init and run functions return void and taking no arguments, no changes to existing modules would be needed.

But one of the reasons to get rid of the two distinct global phases is that some critical modules need the services of other modules while initializing, and those services are available only in the run phase. So we work around by moving part of the initialization to the run function of those modules, and prevent calling most run functions until those critical modules are ready. Manually, of course. -- Boy, that's hard to express in english. In code, it looks about like this:

int main(void)
{
    SystemInit();
    Foo_Init();
    Bar_Init();
    Baz_Init();
    // and so on
    for(;;) {
        Foo_Run(); //< module that "Bar" depends on
        Bar_Run(); //< critical module
        if (Bar_IsReady()) {
           Baz_Run(); //< "normal" module
           // and all other "normal" modules
        }
    }
}
[download]

Other modules originally had a long-running init function, but no run function. Again, we hacked around by moving parts of the init function to a new run function that will be called only until the long-running init is done:

int main(void)
{
    SystemInit();
    Foo_Init();
    Bar_Init();
    Baz_Init();
    Abc_Init();
    // and so on
    for(;;) {
        Foo_Run(); //< module that "Bar" depends on
        Bar_Run(); //< critical module
        if (!Abc_IsDone()) {
           Abc_Run();
        }
        if (Bar_IsReady()) {
           Baz_Run(); //< "normal" module
           // and all other "normal" modules
        }
    }
}
[download]

I'm not willing to go back to that situation. The trick of replacing init functions with run functions in the function pointer array automatically resolves that problems. Any module can use any run-time services of any other module it depends on from its init function, and each init function can run as long as required.

But I will definitly discuss that idea of a perl script instead of the linker for generating the function pointer array at work. Both ways need to touch modules that expect arguments for XXX_Init() and/or XXX_Run(). Both ways need to touch modules that depend on other modules to add the dependency statements. And there is also a minor issue with the code that generates the version number, so we will probably have to scan each module during build anyway. Both could be merged into a single perl script.

Linker scripts are part of each project, they are in a repository like all other source files, so modifying them is no big deal, and we already modify the linker scripts for other reasons. We also use perl as part of the build process, with all scripts in the repository. Both ways are possible, but both look like voodoo to interns and freshly hired developers that know C only as a subset of desktop C++, and to the old developers whose main experience is with DOS/Win-16 and 8-bit microcontrollers with horrible toolchains. 32-bit ARM and GCC are significantly different, and require a different way of doing things. So maintainability will be part of the discussion.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

the title of this writeup reminded me of this recent IOCCC winning entry

*g*

I've hacked a working prototype module for internal discussion. The header file has about 300 lines of Doxygen documentation and about 30 lines of code, mainly function prototypes and macros. The source file has about 40 lines of code, plus a little bit of doxygen documentation.

Compared with our other modules, the relation between documentation and code in the source file is normal, may be a little bit short, but the documentation of the header is unusually verbose. Typically, the doxygen lines are twice or three times the number of code lines.

The prototype is still a little bit rough, it still needs some paranoia checks and some cleanly documented ways for advanced use of the mechanism. That will increase the code size by about 20 lines and the documentation by about 100 lines.

So yes, some parts of the code may look like coming from the IOCCC, but it's only the code. The documentation explains what happens, why and how, as usual for our projects.

---

In fact, I actually use code from an IOCCC winner at work:

IOCCC winner 1984

int i;main(){for(;i["]<i;++i){--i;}"];read('-'-'-',i+++"hell\
o, world!\n",'/'/'/'));}read(j,i,p){write(j/p+p,i---j,i/i);}
[download]

It's in a presentation for interns and freshly hired people, on one of the first pages, right after a picture of the HGTTG with the "don't panic" in big friendly letters. That piece of code is a really good example of bad code, on many levels. What follows is an introduction to the way we write code and documentation, why and how we do it, which modules are a little bit special, common errors, trouble with legacy code, and how to debug.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)