New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incomprehensible error #318
Comments
Unfortunately, I don't know too much about rust (I want to learn more - but there is never enough time) - and why it might not be able to interpret things properly when run through the extension (we do some things were we parse things from objdump which may break if something ends up in a format we didn't expect - but I wouldn't have expected this to effect simply setting/hitting breakpoints). I know some people (@Samonitari and @perlindgren have I believe) had used it in the past with rust - although maybe something has changed that has caused it to stop working. Don't know if they might have any feedback about what they may have been doing differently. |
I did modify the parser for the objdump output to handle de-mangled names for C++ and Rust and to handle IAR generated excutables.. @muttering-oldman Can you provide just the executable and take a look. And, what do the list of breakpoints look like.
I have seen this all the time because when a reset happens, it appears like a breakpoint be hit or a hard fault but the reason gdb receives is unknown reason. It is not fatal. But from this issue, I don't understand what is actually not working. gdb may not be liking the elf file produced to enable breakpoints?!?! |
@haneefdm I'm afraid I didn't quite get it about the breakpoint list. Where do I need to look? Is this an extension output? This is what I see after setting a new breakpoint:
Noticed that the paths in some places have a strange look. Pay attention to the "/" at the end.
I've noticed four variants of the same path. Maybe that's the reason? |
Hmmm, unless it comes from disassembly, we don't mess with path names or line numbers. They go directly to gdb and itinterprets them. The double back-slashes and forward slash are generally okay. Even multiple of them. They are generally collapsed into one From your last attachment, everything seems to have worked. gdb did not fail, did it? So, what is not working? |
Breakpoints do not interrupt program execution. I put them everywhere in the code, but none of them worked. Maybe I'm doing something wrong. |
In the debug console, can you do a |
After connecting, I executed the command "load". But unfortunately the breakpoints are ignored and the execution is not interrupted. I'll continue researching and supplement the information.
I think when I use "objcopy" to convert raw ELF to bin something happens that disrupts the order in which the device performs. |
Looks like the program is in some sort of a blocking delay loop when you interrupted the program Is it possible you have an infinite loop or the delay is too large? If gdb cannot stop at a breakpoint, then there is not much Cortex-Debug can do. |
I should close this issue because the message is coming due to OpenOCD and it does not impede anything and it has always been there on a reset. We know that gdb stopped but it doesn't know what the reason is and we are reporting back to you. I think we are mixing up multiple issues and the message may be incomprehensible but what else should it say? The bug is really with OpenOCD where if the program stops, it should always give a reason. |
Hi guys!
I've been trying to run the debugger for two days, but still got no result.
I'm using st-link + stm32f407vet6.
Running OpenOCD and GDB from terminals everything works. I can do "next", "step", etc.
But an error is happening in vscode. The openocd server starts up normally, but when gdb is connected it says:
The line that begins with the address
0x000032f6 in ...
changes with every start.In this case, breakpoints are ignored wherever I put them.
Sometimes after starting the debugger, execution stops for some reason at line 489 (pub unsafe ...) in the
cortex-m-rt-0.6.12/src/lib.rs
file:There is a stop in other files, but very rarely.
Maybe I'm doing something wrong, but I've tried everything and it still doesn't work.
Debug console from start to stop on the line
pub unsafe extern "C"
Continuation after clicking "continue"
Adapter output:
openock.cfg :
launch.json :
Let me know if you need any more information on this error, I'll try to get it.
The text was updated successfully, but these errors were encountered: