Add debug build profile note #1195
Conversation
…n debugging with the default debug profile.
Fix note formatting, and edit for precise language.
| - Easy to step through code with a debugger. | ||
| - Disabled sleep mode. | ||
|
|
||
| <span class="notes">**Note:** The debug profile uses optimization flags that may cause unwanted behavior during debugging (such as out-of-order jumps and optimized-out variables). If this occurs, you can set the compiler to the lowest possible optimization setting (for example, change `-Og` to `-O0` for GCC). See your toolchain's documentation for more information.</span> |
There was a problem hiding this comment.
Is this behavior unexpected or expected just unwanted?
There was a problem hiding this comment.
I would say it is unwanted. It seems the justification is that code size with -O0 would be too large for some of the more constrained targets. See the discussion in the attached closed PR from the mbed-os repository.
I just want this documented/resolved somewhere so that other developers don't experience hours of frustration figuring out why debugging isn't working as expected.
There was a problem hiding this comment.
@0xc0170 @mark-edgeworth @maclobdell @kjbracey-arm @bulislaw Continuing conversation from ARMmbed/mbed-os#12165
There was a problem hiding this comment.
I suppose that it could be either unwanted, or unexpected, or indeed both! If the user is unfamiliar with the described behaviour then this could be unexpected to them. If they are trying to debug a piece of code in a section that has been reordered then this could well be a nuisance. Either way the note covers it.
There was a problem hiding this comment.
The wording of the docs seems fine to me but what is the point of the debug profile if you can't actually debug with it?
There was a problem hiding this comment.
@kjbracey-arm
Any thoughts after 6 months?
I don't think I've tried -Og with the updated GCC compiler version Mbed supports now. I can see if it helps with debug-ability but I don't think it will be comparable to -O0.
Last time I tried there were a bunch of missing or "optimized out" symbols and random jumping between code lines when I tried to step. I thought I was losing my mind until I checked the build profile and saw the new optimization flag.
There was a problem hiding this comment.
Quick experiment for an RTOS example:
Debug (-Og)
| Module | .text | .data | .bss |
|---------------------------------|---------------|------------|----------|
| [fill] | 52(-50) | 4(-4) | 23(+0) |
| [lib]/c.a | 5072(-23228) | 2108(-364) | 89(+0) |
| [lib]/gcc.a | 760(-2344) | 0(+0) | 0(+0) |
| [lib]/misc | 180(+0) | 4(+0) | 28(+0) |
| components/802.15.4_RF | 16(+0) | 0(+0) | 0(+0) |
| drivers/source | 186(-8) | 0(+0) | 0(+0) |
| hal/mbed_critical_section_api.o | 104(+0) | 0(+0) | 2(+0) |
| hal/mbed_gpio.o | 64(+0) | 0(+0) | 0(+0) |
| hal/mbed_ticker_api.o | 1206(+0) | 0(+0) | 0(+0) |
| hal/mbed_us_ticker_api.o | 34(+0) | 4(+0) | 64(+0) |
| hal/mpu | 136(+0) | 0(+0) | 0(+0) |
| main.o | 668(-16) | 0(+0) | 720(+0) |
| platform/source | 5352(+1382) | 260(+0) | 289(+0) |
| rtos/source | 10002(+0) | 168(+0) | 6101(+0) |
| targets/TARGET_STM | 6088(+0) | 4(+0) | 348(+0) |
| Subtotals | 29920(-24264) | 2552(-368) | 7664(+0) |
Total Static RAM memory (data + bss): 10216(-368) bytes
Total Flash memory (text + data): 32472(-24632) bytes
Extended debug (-O0)
| Module | .text | .data | .bss |
|---------------------------------|---------------|----------|----------|
| [fill] | 90(+38) | 4(+0) | 23(+0) |
| [lib]/c.a | 5072(+0) | 2108(+0) | 89(+0) |
| [lib]/gcc.a | 760(+0) | 0(+0) | 0(+0) |
| [lib]/misc | 180(+0) | 4(+0) | 28(+0) |
| components/802.15.4_RF | 422(+406) | 0(+0) | 0(+0) |
| components/wifi | 178(+178) | 0(+0) | 0(+0) |
| drivers/source | 1402(+1216) | 0(+0) | 0(+0) |
| hal/mbed_critical_section_api.o | 150(+46) | 0(+0) | 2(+0) |
| hal/mbed_gpio.o | 190(+126) | 0(+0) | 0(+0) |
| hal/mbed_ticker_api.o | 2184(+978) | 0(+0) | 0(+0) |
| hal/mbed_us_ticker_api.o | 48(+14) | 4(+0) | 64(+0) |
| hal/mpu | 216(+80) | 0(+0) | 0(+0) |
| main.o | 806(+138) | 0(+0) | 720(+0) |
| platform/source | 8638(+3286) | 260(+0) | 289(+0) |
| rtos/source | 16970(+6968) | 168(+0) | 6101(+0) |
| targets/TARGET_STM | 9190(+3102) | 4(+0) | 348(+0) |
| Subtotals | 46496(+16576) | 2552(+0) | 7664(+0) |
Total Static RAM memory (data + bss): 10216(+0) bytes
Total Flash memory (text + data): 49048(+16576) bytes
From the GCC docs:
Optimize debugging experience. -Og should be the optimization level of choice for the standard edit-compile-debug cycle, offering a reasonable level of optimization while maintaining fast compilation and a good debugging experience. It is a better choice than -O0 for producing debuggable code because some compiler passes that collect debug information are disabled at -O0.
So the two options we are looking at are:
- Keep -Og and document the possible issues and the manual move to -O0
- Change debug to be -O0 and document that if the resulting binary is too big you may use -Og
I don't have strong opinion and would like us to go with option that works best for most people. From my experience -Og worked fine for most times I had to debug something, but I guess it varies a lot.
@donatieng @evedon @AnttiKauppila @SeppoTakalo @mikter @jamesbeyond @pan- @kjbracey-arm any strong thoughts?
There was a problem hiding this comment.
My opinion here is that -O0 should be the default with instructions to move to -Og if there is a space issue. At least this way the user is aware that debugging may not behave exactly as expected and they have made a conscious choice based on their situation.
There was a problem hiding this comment.
No i don't agree, the toolchain docs clearly state -Og is good enough for most of the use cases. I know it's not always the case, but from my experience it worked fine most of the times. And when it didn't it was very clear what's going on. I'd like to keep it if there's no huge amount of evidence that it's not good enough. Moving to -O0 will have implications on explosion of rom size and also stack usage.
There was a problem hiding this comment.
No i don't agree, the toolchain docs clearly state -Og is good enough for most of the use cases. I know it's not always the case, but from my experience it worked fine most of the times.
Ever since the change I have had trouble debugging while building with the GCC ARM toolchain.
And when it didn't it was very clear what's going on.
It won't be to less experienced developers. On some teams the toolchains are set up by senior developers that understand the implications of changing build flags. Mbed isn't Arduino (though Arduino can be Mbed sometimes I guess 😕 ), so we aren't as obligated to cater to beginners in embedded programming.
That being said, I was confounded the first time optimization actually affected my debugging experience. I come from a hardware background and started using Mbed at a startup a few years ago. There were no senior developers that could have quickly explained what was happening and fixed it. Build flags always looked confusing to me so I just glanced over them.
A few years on now, I knew better when the build profile was updated and I started seeing erratic debugging behavior.
I'd like to keep it if there's no huge amount of evidence that it's not good enough. Moving to -O0 will have implications on explosion of rom size and also stack usage.
From a semantic standpoint, it would make sense to me to do the following so we are both happy:
-
Change debug build profile to no optimization (
-O0). Developers using the debug profile expect to be able to debug without any issues. Any optimization could cause confusion. -
Change the develop profile to "debug-optimized" optimization (
-Og). Since this is the default build profile used by the online IDE and mbed CLI it makes sense that full debugging shouldn't be expected. That way we get the size optimization from-Ogand when problems occur that need better debug behavior the user can build with the non-optimized debug profile
The develop profile currently has the same optimization (for GCC at least) as release, which I don't think makes very much sense. The solution proposed above gives more diversity in default build profile options and adheres closer to what the name of the build profile infers.
| - Easy to step through code with a debugger. | ||
| - Disabled sleep mode. | ||
|
|
||
| <span class="notes">**Note:** The debug profile uses optimization flags that may cause unwanted behavior during debugging (such as out-of-order jumps and optimized-out variables). If this occurs, you can set the compiler to the lowest possible optimization setting (for example, change `-Og` to `-O0` for GCC). See your toolchain's documentation for more information.</span> |
There was a problem hiding this comment.
I suppose that it could be either unwanted, or unexpected, or indeed both! If the user is unfamiliar with the described behaviour then this could be unexpected to them. If they are trying to debug a piece of code in a section that has been reordered then this could well be a nuisance. Either way the note covers it.
|
Also it seems that other "auxiliary" build profiles have been added in the past, as evidenced by the subdirectory here: https://github.com/ARMmbed/mbed-os/tree/master/tools/profiles/extensions So why not put a "small-debug.json" build profile in there and let the majority of developers who want straightforward debug sessions use I don't know who has the final say on this so I'm not sure what to do. |
|
I forgot about the extension there 🙂 That might be a good option (question about who updates this extension when profiles change is another question but we can make it work). We would not be having this if tools would provide option to override some of the profiles without creating a new one. Let's find out what the new update brings! Before we jump to conclusion, @ARMmbed/mbed-os-tools How this will be solved in the near future? Do we need to spend more time on this new debug profile if updated tools will have an option to overwrite this easily? |
|
@0xc0170 I would be interested in capturing requirements here, for the tools we are working on. The problem isn't as simple as I would like for tools to resolve. It would be relatively simple to allow the user to override the entire command line, but that is unlikely to useful. What kind of user experience would be useful is this situation? |
|
This may be a bit off topic but while we're discussing built tools: I've heard rumor of a plan to switch Mbed over to more mainstream build tooling in the future (hopefully not manually-managed Make or any derivative of the sort...). If that is the case, it'd be nice to be able to have some sort of module framework/system for Mbed. Kind of what Mbed libs accomplishes now but more flexible. Something akin to a package manager like what python has. Instead of having all these extensions and extra code as a part of the master repo they could be Mbed modules that have their own tests and can be built with different settings. When users submit new packages they can be vetted based on a few standard Mbed tests (style, etc) and then have user-written tests as a requirement to be accepted into the Mbed package repository. Allowing each module to be built with different settings can help users save space by optimizing modules/code they don't need to debug. Code they suspect has bugs can be built without optimization. This kind of behavior would obviate the need for a slightly different debug build profile that shaves a bit of ROM in most cases. Each compiler toolchain has so many different options it makes it hard to present them in a clean way. It also makes it hard for beginners to decide what settings they should use (which is why default build profiles are offered in the first place). Lots of brainstorming here that may not all be completely related to topic at hand. Should this discussion be moved to a forum thread? |
Yeah @madchutney is working on new CMake based build system and I have a design document (ish) about building Mbed from a module like components and directory cleanup. The dependency management is something we discussed before (and had before pre Mbed 5 - yotta). I'd like us to go there, within reason, not crazy Mbed 3 thousand repos mess, but that's for the future. There are plenty of more pressing issues we need to address. |
|
Are further changes required for this PR? |
Not as far as I'm concerned. |
|
@bulislaw Do you require further changes? |
|
ping @bulislaw |
Add note by applying changes from PR #1195 to v5.15.
Updated build profiles documentation to point out possible issues when debugging with the default debug profile.
Related to ARMmbed/mbed-os#12165