Static symbols considered harmful #269
Comments
|
Sorry if I've missed the context, but what's the actual problem with not including static symbols in object files? |
The symbols are actually included in the object files, and the debugger has no problem finding them. |
|
But I like self-contained modules and not having to worry about names clashing with other modules. Eg, I can define the same function name in 2 separate files, have it static, and not worry about a name clash. To prevent this, you need to name all functions in a file as though they are in a global namespace. |
|
Making things static also helps the optimiser, as it can make more assumptions if it can see all users of a function (or data). eg leaving out unused ones to save space. :-) |
I like that too, but what to do if toolchain has gaps in overall support of them throughout the development process?
Unfortunately, situation is far from being able not to worry. For example, try to do "disass emit_pre" in gdb - it will show a random one, without telling which, and without giving a hint there're others. So, just to clarify, I propose to change almost all static's to STATIC, and have that defined to "static" as before. For "analysis" builds, it will be defined to empty string. str_join dup case is easy to fix, emit_pre can stay as "static", though I'd go for prefixing it and doing |
|
As pointed out above by @jugglerchris, proper static is definitely needed for proper optimisation (given that the compiler is good enough; gcc is). I also don't like macro creep: that everything starts to be written in a custom macro-language within C. For efficient embedded code, that's kind of a necessary evil. But still would like to keep things non-macro based if possible. Anyway, we can go ahead with this change, using STATIC instead of static for functions. What about static data? |
Not challenging that, but to keep up the conversation: indeed, static allows for limited (intra-module) optimizations, but if someone is after optimization, then the way to do it is whole-program optimization. Then surprisingly it's not important if symbols are marked as static or not (compiler treats all symbols as such).
Well, we're getting of the original topic, but why then we have stuff like MP_OBJ_NEW_SMALL_INT()? It makes eyes burn and breaks continuity in the API. I understand intention to remind that it's a macro and can have side effect issues due to double evaluation, but that function is part of API set, and should be named consistently, and any (if at all) side effect issues should be resolved separately. We may also want to switch to inline functions, but ironically, to get them working decently, we'll again need stuff like "INLINE".
The idea is that all global symbols should be "STATIC", exactly to allow locals to be freely "static" if needed (local statics are unlikely needed for language core, but who are we to disallow their usage in hw drivers, etc.?) |
|
Ok, done. Trivia: |
|
Okay, very good. I agree with you re |
|
Ok, let's close this, I opened #293 for macro/inlines issues. |
... by the GNU tools themselves, see e.g. http://stackoverflow.com/questions/21679940/include-static-symbols-in-gnu-ld-map-file , expected outcome: that's not possible.
So, instead of "static void foo()" we should do "STATIC void foo()", and then define STATIC up and down. Let me know if you agree and I can proceed with the changes.
The text was updated successfully, but these errors were encountered: