4.9 debug build strips debug information

Hi Stefan,

Indeed, the target libraries are still stripped as the debug build concern the host tools. Building with debug profile means all debug symbols are kept for the compiler, linker, etc. I agree the name is misleading as it doesn't indicate what will be debugged (in this case the toolchain itself). The problem of having debug symbols in the target libraries is that it makes them bigger and it might not fit in flash (I'm not sure if gdb strip the debug info before uploading an elf file, Terry can confirm that).

I hope that answers your question.

Best regards,

Thomas

Yes, the gdb will omit the debug info when uploading. Here the option 'debug' means we use '-g' to build arm-none-eabi-gcc and others, not the newlib.

Thank you both!

I didn't occur to me that the debug build was intended to debug the host tools, but of course it makes sense now that you have pointed that out.

However, I find it desirable to improve the debugging of target code. Currently, there's no support for stepping into library code and work there on the source code level. I'm sure I needn't say how inconvenient it is to debug on the disassembly level.

As Terry confirmed, keeping debug information in the libraries will not actually increase the size of the target executable, so there's no need to strip the libraries for conservation of flash space on the target system. However, the debug information will of course increase the consumption of disk space on the host machine. Nevertheless, I would appreciate if there were a build option that kept the debug information in the libraries. As far as I have seen, the libraries are built with the -g command line option, and only in "Task [III-10]" the debug information is stripped. So it looks to me as if it would suffice to skip this step, and one would end up with the libraries including the debug information.

Is my observation correct or is there more to be done?

If it should be that simple, I would vote for introducing such an option (perhaps named target-debug) in the build script.

Cheers
Stefan

Hi Stefan,

I am thinking this. But since a lot of newlib functions are implemented in assembly code for performance purpose, not sure it will help so much if we don't strip them. By the way which newlib functions are you most interested in?

In general, I am interested in functions which might crash because of a wrong parameter that may have been passed in. Since that can happen with a lot of different functions, and deep in the call stack, it wouldn't be easy to provide a list.

Anyway, wouldn't it be more work to selectively enable debugging? In my opinion, leaving debug information in the library for everything, even the functions written in assembly, would be both the most useful, and the simplest option. After all, even when the source is assembly code, leaving debug info in allows to look at this source code, which may be commented, rather than seeing an uncommented disassembly.

Cheers
Stefan

Thanks for explanation and they do make sense to me. Please allow us to discuss it internally.

Plan to extend the option --skip_steps to allow to skip the strip steps to keep the debug information in target library. But the build script change can only happen to 5.0 major release in 2015Q4.

Please discuss in related bug entry.