This might be a newbie question, but I am going crazy already haha.
symptom
I am having an issue with the lpcxpresso54102 Dev Board, where I am not able to access main.c during debug session, but if I check on the disassembly window I can see the main file, instruction set and actually the project works and I am able to set breakpoints through disassembly. disassembly_data
symptom
If I place a break point on main.c, when I start the debug session, my breakpoint is replaced by a circle with a exclamation point inside the circle. Browsing through ARM dev QA site, I was able to find that this issue is related to
NO CODE AT BREAKPOINT: A breakpoint could not be set because there is no code generated for this source code line. Compiler or linker optimization can remove unnecessary source code.
ARM_DEV_QA
NOTE: optimization config. was modified from original project to 0 optimization level.
symptom
Once I enabled the option for debug information on the target configuration, the file "startup_LPC54102_cm4.s", the cursor was actually going trough the file and eventually reaching the infinite loop used to toggle the led on the board.
NOTE: This file is the example code from the SDK example lib from NXP (blinky), but all the other examples behave the same in UVision, but if I tried on MCUXpresso IDE the debug session works just fine.
Also I checked the linker files and they seem to be ok.
I changed the configuration on the target of Uvision enabling the output info and also changing the optimization to level 0, checked the compiler control string on C/C++ tab and it seems that all the files path and controls are there (no completely sure though). I tried with external and internal debug HW, same behavior.
Related
Im working on Arduino Uno board recently im stuck with my code, i couldnt debug using print() in ArduinoIde.So i downloaded AtmelStudio 6.2 for debug purpose.
when i set the breakpoint and try to build .Im getting the warning
The breakpoint will not currently be hit. Unable to set requested breakpoint on target.The current selected deviceis unable to set breakpoints during runtime
please help me sort this issue
Following workarounds worked with the same problem using ATMega 168P on Atmel Studio 7 with Atmel-ICE.
1. Assembler
Insert the following assembler code where you want your breakpoint:
asm("break");
Please note, this is a really ugly solution and not suitable for all situations. It only works with DEBUGwire and makes your program stop in any case, even if no programmer is attached.
2. Create new project
Creating a new project at a different location helped as well. I copied all the required files to the new folder. The new location has a short path (C:\atmel\project...) and contains no spaces, no umlauts etc.
I had a similar problem, the difference was that I could only hit breakpoints in the original modules of my project (i.e. those already existent when I created the .cproj), any modules I added later wouldn't have the program stopped in breakpoints placed on them.
The solution (2) mentioned by #pafodie worked to solve this, but in the process I found a simpler way: just delete the .atsuo file. It will later be automatically recreated, and the problem disappears (at least until you add more modules). It seems AS6 caches something there that isn't updated when new files are added, or does it incorrectly.
I might've found a solution that works, for me at least! You need to disable compiler optimization. In Atmel Studio,
Hit Alt+F7 > ToolChain > Optimization {there are 2 Optimization
windows but only one fits the shoes} > Optimization level > None
I found it here, explained better than I did: https://www.microchip.com/webdoc/GUID-ECD8A826-B1DA-44FC-BE0B-5A53418A47BD/index.html?GUID-8FF26BD2-DBFF-48DD-91FB-8585D91A938D figure 5
If using external Makefile, make sure the -g (debug) flag is set in CFLAGS.
Otherwise, Atmel Studio would have no idea how the source files correspond to the compiled binary.
Is there a way to tell pyCharm that it should skip framework code? The debugger should skip all lines which are not from me.
In my case it is very easy to tell which code I want to debug and which not:
Code in virtualenv lib should be skipped
Code in virtualenv src should be debugged.
If I press F7 (Step Into) it should skip all lines which are not from my code base.
[Update May 2015: introduced in PyCharm 4.5]
There are two new features now, one of which is the one you asked for, but I mention the other one as well because it is topically very close.
From the 4.5 release notes:
Step into My Code
Stay focused on your code by telling the debugger to step only through your project code, as opposed to stepping through the library sources.
[...]
Ignore Library Files
The debugger is improved with the new 'Ignore library files' option. Use it to have the debugger stop inside your code in case the exception is raised in a library module, instead of stopping inside the library code.
[Update after learning about blackboxing libraries in debugging]
In this answer it is mentioned that you can add the modules to ignore into "the dict DONT_TRACE in /helpers/pydev/pydevd.py"
And there is an open issue on the issue tracker.
[original answer]
It is not possible to skip code like that, but you can flexibly switch between walking through the code line by line and making bigger jumps in a running debug session by simply adding another breakpoint (while debugging - break points can be changed in a running debug session) at the position after the library code you want to skip and press 'Resume Program' in the Debugger. The library code is skipped and you are back in your code.
You might also want to use conditional breakpoints to make sure that the program breaks into the debugger exactly when the program is in the state that you desire: right click on a breakpoint and enter a condition that has to evaluate to True in the context of that line.
I am using Visual Studio 2010 to debug an application mostly written in C. Normally, I can attach the debugger just fine, but I am running in to some problems when I link in a library written in C++ / CLI.
If I compile the library with the /clr flag (which I will eventually have to do for this as of yet unwritten library) then I lose all ability to debug the entire C application, even the parts that have nothing to do with the library calls. I get the empty circle with the yellow triangle and exclamation mark where a red break point circle ought to be. Hovering over it gives me only a tool tip that says "The breakpoint will not currently be hit. No executable code is associated with this line. Possible causes include: conditional compilation or compiler optimizations."
Then if I link with the exact same library compiled without the /clr flag, I am again able to debug my application.
I understand that visual studio will not likely be able to debug the library written in C++ / CLI, and that is OK. I just want to keep the ability to debug the rest of the application and at least see the results of my calls to the external library.
Another complicating factor is that this project is not being built by visual studio. It is compiled using an external make system that uses cl, so I can customize any commands that need to be issued to the compiler that way.
Does anyone know why I can't currently debug the libraries the way I want to? Any advice for how I can?
You have to select the kind of debugger when you attach. Note the "Attach to" label in the dialog. Press the Select button and tick "Native" to get support for debugging native code. The DLL also needs to be loaded before any of your breakpoints can hit. If you are not sure whether or not that was done then look in the Debug > Windows > Modules debugger window to see loaded DLLs. The breakpoint indicator turns from hollow to solid red as soon as the debugger saw the DLL load and armed the breakpoint.
Debugging C++/CLI is otherwise supported, you can tick both the "Managed" and "Native" checkboxes. And set breakpoints in either kind of code. The only thing not supported is single-stepping from managed to native code and back. A mode-switch is required to activate the correct debugging engine, that requires code to hit a breakpoint.
And consider the Debug options in your native project, you can specify an EXE to start. So that you can simply press F5 to start debugging and skip the attach hassle.
It might also have to do with the Debugger Type!
(but that depends on your specific building configuration about which I do not know enough)
If any of your projects is complied with Common Language Runtime Support (/clr) you should set the Debugger Type in your startup project to "Mixed", since the default setting "Auto" might fail!
Imagine, you have two projects:
1) A non-CLR C++ project, which is your startup project that generates some .exe file.
2) A C++ project, that generates mylibrary.dll, which is compiled with Common Language Runtime Support, because it uses some managed code. The .exe from the first project calls mylibrary.dll.
If you start the first project with Debugger Type set to its default value "Auto", you'll be able to debug into the first project, but not into the second one. The debugger selector does not realize that you will be calling a CLR-library.
So set Project Properties -> Configuration Properties -> Debugging -> Debugger Type to "Mixed"!
I've got a little problem. my application runs without problems in Debug mode, but crashes in release mode. I can't track down the problem, because in release mode all the Debuginfo appears to be nonsense. However - sometimes in other projects the Debug output is also valid in release mode. What projectsettings do I have to change such that the Debug output is valid in release?
thanks!
Even in Release mode "Generate Debug Info" should be set to "Yes" per default. The problem is that when you're running in Release Mode the compiler optimizes the code which makes it hard for the debugger to display the correct values of variables (it may for instance choose to keep some variables in registers etc.).
There's not much to be done about this, you could always turn off optimization either globally or around a specific function using #pragma optimize ("", off) / #pragma optimize ("", on) around it but this essentially means you're running in Debug Mode again and the crash will probably go away...
If you're comfortable with reading assembly code, you can switch over to disassembly mode and through a little investigation find the correct values of your variables.
Likely, you're making use of uninitialized variables.
In your project settings, set
Configuration Properties > C/C++ > General > Debug Information Format
to Program Database
Then, set
Configuration Properties > Linker > Debugging > Generate Debug Info
to Yes
The good old "debugging with traces" approach may help you having a rough idea of where the problem is. Then read this portion of the code again and chase uninitialized variables.
My problem is that I set some breakpoints in my code and some of them aren't working. In some places it complains about "Unresolved Breakpoint".
Does anyone have any clue why this is happening? I am using gdb, by the way.
EDIT: Yes, of course is compiled with debug information. It only happens at some classes or points in the code. And I am pretty sure that that part of the code is reached because I can reach it stepping
EDIT: The solution from Richard doesn't work; thanks anyway. I am compiling in Debug, without any optimization.
Could it be that you are trying to set breakpoints in a shared library that has not been loaded yet. That won't work until the library has loaded. Newer gdb allow to set deferred breakpoints, but that may not (yet) be supported by CDT. A workaround is to set a breakpoint in a place that is available from the beginning that will be reached when the shared library in question is already loaded. Then set the other breakpoint in the shared library. Now it should work. It's a bit more tedious, but usually works.
From the GDB documentation:
For a pending breakpoint whose address is not yet known, this field will contain 'PENDING'. Such breakpoint won't fire until a shared library that has the symbol or line referred by breakpoint is loaded.
I have found that sometimes switching the referred Process Launcher from "GDB (DSF) Create Process Launcher" to "Standard Create Process Launcher" has fixed this problem for me. Other times, just deleting all breakpoints and restarting Eclipse does the trick.
"Unresolved Breakpoint" just means that GDB did not find code location corresponding to the file and line on which you attempted to set a breakpoint.
Are you trying to stop in a constructor?
If so, you are likely seeing this cently fixed GCC bug.
Sometimes optimizations will cause breakpoints to be skipped as well. Make sure you're compiling with -O0
I have found that using F8 (resume) doesn't stop at my breakpoints. But, if I have Stop On Startup : main set then then step over my code (F5/F6) then my breakpoints are hit. I don't have any special compiler options other than -g or -g3. Hope that help...
Make sure the breakpoint type is correct. For C/C++ it's a tiny blue dot. If it looks like anything else, chances are the breakpoint type is incorrect. I would try to close the file, right click on it -> open with -> C/C++ Editor. This worked for me.
If other answers here didn't solve your problem, it is possible you are having the same problem I had (which was the result of having an outdated version of GDB). This is likely the case for anyone using GDB on Mac.
See my question and answer here:
GDB does not break on some lines of code when using multiple source files
Do you place a breakpoint in a template class/function? I've met the same problem: I can step through the code of templates but breakpoints do not work.
I guess eclipse does not understand that it has to place breakpoints in all instantiations of that class:
template <typename T>
int doit(T a) {
return a.do(); // <-- breakpoint here
}
...
A a;
cout << doit(a);
I think it will wait for doit(...) and never for doit(...).
At lease gdb itself stops on the breakpoint if I set it to the function: 'doit'.
I had a similar issue with GDB. It seems that it was caused by identical source code filesnames even if they have different paths. I renamed the duplicates and GDB worked just fine after that.
Silviu
i had the same problem,
1.- Removed the breakpoints.
2.- Restart eclipse
3.- Clean the project by using project -> clean
4.- Add again the breakpoints and start your debugging.
This solved my issue.
IF you are using GDB as a debugger, make sure you are using both flags:
-g and -ggdb
You can either edit the make file directly,
FCFLAGS = -g -ggdb (some other flags you might have)
or go to Debug Configuration (It's in the menu that drops down when you click on the little arrow besides the bug icon.) Select the project you are debugging, and click on the debugger tab. Check you are using gdb, and add the flags here.
Amazing that there are so many different answers to this question. There is still (2020) a problem in Eclipse 2019.12, CDT 9.10, RHEL 8.0, x86_64. In my case, I can fix it by adjusting the breakpoint properties, and changing it from 'regular' to 'hardware' (select the breakpoint window, then right-click on the breakpoint, Breakpoint properties, common, type).