I'm using QT Creator on 3 platforms to create platform independent software. However, I'm getting a segmentation fault with the exact same code in Windows only. That doesn't sound so bad because I can use the debugger. Except, no matter how many breakpoints I set or where I set them, they are ignored by the debugger. I am 100% sure that my control flow is going through the breakpoint but not breaking the flow.
Any thoughts? How can that happen?
Doh! I was using Cmake with Qt and I failed to set the CMAKE_BUILD_TYPE variable. That was it!
Related
I'm using SSDC Compiler for PIC micro-controllers, and it supposed to have a supported debugger called (SDCDB). Although, in compiler settings it shows Invalid Debugger in debugger option. So, how can I specify the SDCDB to be my default debugger. And, is there any problems using GDB with SDCC compiler?
This only answers part 1 of your question. I don't know what happens when you use gdb with SDCC.
You will need to be an admin user for this
Look for options_sdcc.xml in %programfiles%\CodeBlocks\share\CodeBlocks\compilers
Open the file in an editor. Look for DBGconfig on the windows platform. Set the value to sdcdb.exe
I am developing embedded C for a TI MSP430 microcontroller, and have spent the last couple days migrating from TI's IDE and proprietary toolchain to a more unix-y workflow of Sublime Text + make + gcc. I'm now trying to set up debugging with WinGDB (Visual Studio with gdb backend) and I've got it mostly working. There's just this one issue with breakpoints which I suspect comes down to a backslash / forwardslash issue, but I don't know how to fix.
I can start debugging without problems, I can step through, view disassembly, etc. But when I try to set a breakpoint in the source file using F9, it shows up as disabled with the hovertext:
The breakpoint will not currently be hit. No source file named d:Documentsccs workspacesmsp430 scratch\013cxmain.c.
Location: main.c, line 13 ('main(void)')
However, I can set and clear working breakpoints with gdb commands in the WinGDB debugger shell, but no little red circles appear next to the source.
The path to main.c is D:\Documents\ccs workspaces\msp430 scratch\vcx\main.c and I discovered that the escape sequence \v corresponds to a vertical tab, or octal \013 in ascii. So I'm guessing the backslashes are screwing something up somewhere (thanks windows).
Any ideas where to look to fix this?
Your error shown is usually generated when your code is optimised by the compiler - such as a = 2; and never used again. But the main problem(s) could be related to your cross toolchain - on this link the cross toolchain implemented in WinGDB is CodeSourcery G++ Lite toolchain for ARM, while your micro, MSP430 is not an ARM device. (there is an MSP432, which is ARM device).
Maybe you can look at this: www. Energia.nu, something similar to Arduino, works with several versions of MSP430.
You are correct that it is a backslash problem, the debug records generated for your files which tell the debugger which file & line resulted in which group of op codes.
You can try modifying your build process to use forward slashes everywhere, since your tool chain is gcc based it should find files named
D:/Documents/ccs workspaces/msp430 scratch/vcx/main.c
but you are also likely to have problems because of spaces in your path, restructure your project so that all spaces are replaced by underscores i.e. D:\Documents\ccs workspaces\msp430 scratch\vcx\main.c gets moved to D:\Documents\ccs_workspaces\msp430_scratch\vcx\main.c etc, spaces in paths can cause all sorts of issues. While it is possible to escape spaces in paths it is better to just avoid them.
I would also suggest taking a look at Code::Blocks - while not as pretty as VS it does a much better job of providing an IDE and debug environment for cross platform and embedded development. It is free, cross platform and open source itself. It interfaces with GDB very well and you can customise the build tool chain that it uses for your project(s). It even comes with presets for GNU GCC for MSP340, as well as many others, so should be very helpful.
I am currently developing a wrapper library in order to start GDB from my application and have it debug a program.
I am using MinGW32 since I am working with the Ada Gnat compiler which is only available in 32 bit on windows. My OS is windows Server 2008R2 64 bit.
I can not start an application in the debugger in the background with "run&". GDB reports that background processing is not available on my configuration.
I am relatively new to GDB and it is my understanding, and my tests confirm this, that I can not send new commands to GDB while the debugg is running and is not in background mode. That means that I can not interrupt the debuggee or in other words, if I forget to set a breakpoint, there is no way to interrupt it, set a breakpoint and continue. Unless it runs in background mode which means GDB accepts commands while the debuggee is running.
My question is: Is this generally so on Windows or does it come from my particular setup?
On which systems should background processing be available?
Background processing requires the "target-async" feature, which is only implemented by the remote and Linux native targets. So, if your gdb is using gdbserver, it may work. Porting a target to be async-capable is not very hard in most cases, but nobody has ever done this work for the Windows native target.
Note that the other comments are correct, though. There's some way to interrupt gdb when using MI on Windows. Unfortunately I am not a Windows expert and I don't know what that is. Nevertheless you don't need target-async to do this.
I am trying to debug a few C++ applications with KDevelop 4.0.1(on KDE 4.4.5 and gdb 7.0.1) on Debian 6.0.6. Irrespective of what part of the code I break into, the debugger detaches automatically after stepping through a few instructions. I didn't find anything on this topic on any forums. I tried a few things below.
Debugging using gdb on shell works perfectly fine.
Tried debugging multiple applications, but the issue is seen.
Reinstalling KDevelop did not help.
Am I missing some configuration that could cause this behavior?
(I am new to kdevelop)
Thanks for any help.
My guess is that is related to pretty printing of an uninitialized variable.
Lots of fixes have been applied to KDevelop and gdb, you should consider updating to a more recent version.
first off, I really need to make a 64bit version of glfwdll.a and glfw.dll (so I can hopefully finally succeed in getting the Go glfw bindings to work under Windows ... was a breeeeze under Linux!)
Seems like I now succeeded in compiling 64bit versions of glfwdll.a and glfw.dll using mingw64, MSYS and their make scripts, even though I did get a couple of error messages along the lines of "maincrt entry point not found, using default 0xsomehexnumber instead" or some such. Entry points of course refer to executables, in this case those in the examples directory.
And indeed, most of them don't work! All got built however. The following executables work:
listmodes.exe mtbench.exe mthello.exe and particles.exe -- the latter being the only graphical (3d gfx) example working for me (the former ones just outputting some test infos onto the console window).
Now what's the issue with the other ones? They don't crash, they don't report anything to the console... I run them, they return immediately, silently.
Is my GLFW build broken? How to fix? What's the big difference between the 4 examples that work and the others that don't?
This is a fairly new, vanilla Win7 64bit installation. No crapware, everything up to date, UAC and Themes are off, not a lot of software installed at all, Nvidia GPU driver updated (GPU Caps Viewer and the likes run fine, so OpenGL is there).
I'm not yet allowed to add comments, so I'll post this as an answer.
The issue you're having is due to three separate bug in GLFW. I fixed them today and the fixes will be included in GLFW 2.7.6. Until then, you can use trunk from the GLFW Subversion repository.
To be sure that you really have no DLL-hell issues with the opengl32.dll, glu32.dll, glut32.dll etc., check out the Event Viewer tool and see if there are some warnings or errors for you app.
This is my thought because you are only able to run the mtbench and mthello which have nothing in common with the "real" OpenGL API.
No clue about particles.exe though - maybe GLFW checks for errors internally and call the exit() routine ? Check the %errorlevel% also.
Also take a look here:
http://glfw.svn.sourceforge.net/viewvc/glfw/trunk/examples/pong3d.c?revision=1110&view=markup
There is a GameMenu() function which may exit silently if "!glfwGetWindowParam( GLFW_OPENED )", which obviously means that OpenGL was not initialized.
The same function serves as an exit flag here
http://glfw.svn.sourceforge.net/viewvc/glfw/trunk/examples/wave.c?revision=1110&view=markup
Once again, double-check the DLLs !
I believe that you are experienced not to make "advanced" mistakes in the build process, so there just might be some funny thing happening at the "user level".
And another suggestion:
http://sourceforge.net/projects/glfw/forums/forum/247562/topic/3868944
Some parameters might not work exactly for you.
To "fix" the samples try commenting out the glfwGetWindowParam call.