Debugger oddities with breakpoints

Recently my project running in mbed studio during a debug session will break at breakpoints I haven’t set and doesn’t appear to break in main as expected. However, if I set a breakpoint in main while the code is running the debugger does break, but the point it “appears” to break at isn’t correct.

I’m using the standard debug.json profile.

Any ideas?

Edit: And just for some further commentary, here is a screenshot of a debug session in which the debugger is clearly breaking at the correct breakpoint in main(), but the line isn’t highlighted and the GDB/pyOCD is saying it doesn’t have line number information.

What could cause GDB information to not have line number information?

And not only that, but when I enter “list main” into the debug console GDB should list about 10 lines of source code around main(). However, the attached image below shows that it’s clearly confused and printing source from some other module.

I’ve had this issue too.

One option is to try to try disabling optimisations.

I found it better to use the GCC compiler.

Neither solutions are ideal and it’s a shame this seems to happen out-of-the-box for non-trivial applications. Others may have better suggestions.

@ChrisSmith42

Thank you. I tried O0 but then the application won’t even run under the debugger.

This is a serious problem and severely limits the usefulness of mBED studio.

Maybe I will have to figure out how to make mBED studio use the gnu compiler.

@ChrisSmith42
So how did you install the GCC compiler?
I supposed it’s documented somewhere?

Thanks again.

I used this link: Switching to GCC - Installing | Mbed Studio Documentation

That post contains a link to download the compiler itself. I installed the latest version and it seems to work fine but the build warns if too new so you may want to try a 9.x version? E.g.:

Compiler version mismatch: Have 10.2.1; expected version >= 9.0.0 and < 10.0.0

Thank you. I will give that a whirl.

Sure would be nice to get some help, or comments, from some of the members of the mbed studio team.

@ChrisSmith42
Is it me, or does GCC ARM take forever to compile mbed OS on Windows?

I’ve found both to be about the same.

The initial ‘build all’ (where the OS itself is compiled) takes many minutes. Incremental builds (just changes to app source) are much quicker (but not what I’d call fast).

Linux appears to be quicker. Under Windows it’s possible to add for anti-virus exclusions for the various tools that are launched; that helped me quite a bit.

Is there a way to enable parallel builds in the make process similar to specifying make -j6 ?
It looks like only one source file is being compiled at a time.

Thank you for the help. Using ARM gcc fixed my debugging issue!

Not that I’ve come across but I assume it’s possible to configure.

On my machine (a reasonable Windows i9) it appears to be doing a number of things in parallel. E.g. Task Manager shows lots on ‘cc1’ processes in this snapshot, overal CPU is at 100%, clean build takes ~6 mins, shortest incremental takes 15 secs.

image

Ok, of course. I didn’t even think to look at Task Manager. I do see multiple compile processes.

afaik, the filesystem is slower on Windows. Even in WSL the compiler runs much faster (when the project is stored in the WSL filesystem). I have a setup where I connect the target to a linux machine and use VSCode whith remote extension. That gives the feeling of native Windows with the speed of Linux.
I haven’t switched yet to the new cmake build system, that should decrease compile times also. Now I’m using a F7 with Ethernet, storage and lvgl graphics, building takes a long time on Windows and the laptops fan is screaming :slight_smile: