Re: Baby X is bor nagain

On 18/06/2024 01:52, James Kuyper wrote:

On 6/17/24 12:21, David Brown wrote:
...

Having a distinction in optimisation between "debug" and "release"
builds is simply /wrong/.  Release what you have debugged, debug what
you intend to release.

 I fully agree that you should debug what you intend to release; but I
can't agree that it always makes sense to release what you've debugged.
There are ways to debug code that make it horribly inefficient - they
are also good ways to uncover certain kinds of bugs.

Yes, as I said I sometimes change things while chasing particular bugs - with sanitizers mentioned as an example.  And I might compile a particular file with low optimisation, or disable particular optimisations to make debugging easier.
Most often, I do this with additions to the source code in question - marking some functions as "noinline" (a gcc attribute) to make breakpoints easier, or marking some variables as "volatile" to make it easier to see them with a debugger, or simply adding some extra printf's.  You do what you need to do in order to find the bugs, and how you do that depends on the bugs and the type of tools you use and the kind of program you have.  But I do not change the rest of the build.
Of course it is correct in a sense that you don't release what you debug, because you debug code that is not working, and you don't release it until it is fixed!
But you should not (IMHO) be using special debug modes for the main part of your debugging and testing, you should be aiming to have as realistic a scenario as you can for the code.  While optimisation does not change the effect of correct code (other than perhaps different choices for unspecified behaviour), few programmers are perfect.  Sometimes code errors will, by luck, give the desired behaviour with no optimisation but erroneous behaviour with high optimisation.  I have no interest at all in having my code pass its tests with -O0 and fail with -O2 - I want to go straight to seeing the problem.

There should be a
debug mode where you enable that inefficient code, and track down and
remove any bugs that you find. Then you go to release mode, and test it
as thoroughly as possible with the code as it is intended to be
released, which is never as much can be possible in debug mode. Do not
release until the final version of the code has passed both sets of
tests. If release testing uncovers a bug that requires a code change,
that means that debug testing also needs to be redone.

There are different development strategies appropriate for different types of program, and different types of development teams.  Splits between development, debugging and testing can vary.
Perhaps my attitude here is unusual, and due to the type of work I do. For me, a "project" consists of all my own source code, all the libraries, headers, microcontroller SDK's, all the third-party source code, the build process (normally a makefile and often a few scripts, including all compiler flags), the toolchain, and the library.
The binary that goes into the product is thus entirely reproducible.  I don't deliver a collection of C files to the customer, I provide the whole build system - and the code is debugged, tested and guaranteed only with that toolchain and build settings.  It is important that if the customer finds a problem years later, I am working with /exactly/ the same binary as was delivered.
Of course I try to make the code as independent of the details of the toolchain, libraries and SDK's as reasonably possible, and I will move over to new versions if appropriate - but that means full re-testing, re-qualification, and so on.