Regarding debug symbols the two referenced issues (with unmerged patches and a bit of build system changes) will correct that.

What other logs/asserts do you think are needed?

Some questions:

• How extensive symbols should be used? -g1, -g2 or -g3?
• Which optimization level? -Og, -O1, -O2, -O3?

Daniel, I filed this task based on a discussion we just had with Monty. We thought it might be handy to have assertions to printf with these binaries (so as not to go unnoticed).

For easier debugging and investigation, the two referenced bugs create packages containing the debug symbols (only) that corresponds to the code as the production releases. This means from a debugging point of view you have exactly the same code running as the production (right down to machine code level). Unlike the currently path of getting users to compile (using different compilers, library dependencies, cflags, ldflag) to assist with the debugging process, or creating a replacement package as this issue alludes to, you end up debugging a different program. The result of build changes the code actually being debugged as its not the same instructions. This results in a different result of compiler optimisations, CPU effects, or dependent libraries meaning the bug may not be reproducible or may exhibit different behaviour.

Adding printf statements into code also changes the code being debugged. Knowing what print statements to put into code up front is very dependent on the problem being solved. So rather than asking users to debug a different bit of code, when a specific issue needs to be resolve provide a gdb script that prints out the exact information required. This can minimally attach to the piece of running server to extract exactly the information required with no down time. Debugging with print statements? - scoff, we aren't in coding school, lets debug like professionals with an appreciation of what an operations environment really is.

From a production dev-ops point of view exactly the same server code and a minimal gdb script is a considerably easier sell to do that trying this replacement binary. The fallback case when running the gdb script it to terminate the gdb process and you are left with a running server which is a lot better than downtime, installing a new binary, and starting up again.

So for the release binaries:

How extensive symbols should be used? -g1, -g2 or -g3? - -ggdb - https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html
Which optimization level? -Og, -O1, -O2, -O3? -O3 of course.

So from my point of view - no special binary packages - just debug symbol packages and gdb scripts.

Is this still an item on the agenda? What is there to be done more specifically, that is different from CMAKE_BUILD_TYPE "RelWithDebInfo" for e.g.?

What about other compilers, as the discussion here seems to imply default GCC.

Easier debugging doesn't normally lead to a conclusion of different compilers.

on items to be done:

• MDEV-16828 is holding up the availability of debug symbols as packages on artful/bionic
• Seems the centos7 (https://buildbot.mariadb.org/#/builders/9) autobake rpm builders no longer using cmake-3.7+ (MDEV-4646) to build RPMs. Are these used for release?
• Are the current debian builders not running with DH_BUILD_DDEBS=1 (MDEV-658)? Is the dh_strip on jessie patched to produce debug packages?