Hello Guido,
your posting does not bode well with me.
On the one hand, you acknowledge that your are unaware of the ramifications of the symbols definition.
On the other hand, you chose to ignore the sentiments brought forward by Christan Helmuth and me.
Your pull request [1] following-up your posting addresses your inconvenience while putting the burden of added technical debt on us by duplicating the list. So we find ourselves not only ignored but also confronted with the expectation that we should be happy to carry forward the added technical debt. That cannot have been your intention.
[1] https://github.com/genodelabs/genode/pull/3112
Given your response, I suspect that our concerns were not expressed clearly enough. So let me try again, using an analogy: There is a country road that enters a village. At the side of the road, just in front of the school, there is a warning sign. The sign is meant to raise attention, to prompt drivers to decelerate, to get conscious about the situation, and - if everything is clear - to slowly accelerate again.
You drive this road for the first time. You see the sign, you get conscious of the situation, but at this time, no children are crossing the road. So your conclusion is to remove the warning sign to make the traffic run smoother though the village. I hope you agree that this wouldn't be a positive contribution to society. ;-)
Granted, the existing "warning sign" is certainly far from ideal. Thanks to your original posting, we recognize that it is (1) confusing and (2) that there is currently no good documentation to interpret the error message. So we should definitely improve.
In [2] you find my take on point (1) - making the warning sign more clear. Point (2) will need to wait until the next time I'll undergo the process of porting a library. I'll enhance the porting guide then.
[2] https://github.com/nfeske/genode/commit/d7fd53cc8e933cdc8b967d7159965b540c18...
What is the effect on security when I leave internal symbols in the ABI? Would a process - that is linked to my library - be severely easier to subvert by an attacker who exploits a buffer overflow?
This is not a security problem but a potential robustness problem. ABI inconsistencies can result in runtime errors. Someone who offers a library should pay attention to the ABI in order to catch errors of library users at linking time, not at runtime.
Generally speaking, an ABI that exposes unofficial symbols is similarly bad as dead code. It smells.
But it's is not solely an aesthetic issue. Imagine porting a library where you use a wildcard to select the source files to be incorporated into the library. If the source directory happens to also contain the source code of a test program, this program will accidentally end up in the library. A review of the ABI symbols catches these kind of problems on the spot. In contrast, if such a problem goes unnoticed, it can produce the most weird kind of runtime errors. I assure you that the debugging of symbol aliasing problems can be very painful.
In short, treating the ABI symbols as a black box is a mistake. I think your desire for convenience is misplaced here.
Reviewing a library ABI is simple enough whenever library symbols are nicely prefixed with the library name. A human reviewer can easily spot such patterns. In contrast, symbols starting with '_' are usually not part of the official library interface.
Norman