I'm working on writing an OS and I'm running into problems trying to debug my code. I'm using GDB to connect to Bochs' GDB stub to "remotely" debug my kernel. Connecting works fine, as does loading debugging symbols from the kernel file. I set a breakpoint for the kmain function, which is successfully located, and the debugger breaks correctly (inside my kernel). However, I can't "step" or "next" through my code, nor can GDB apparently determine which line of code is the current line.
When I try to "step", I get the following message: "Cannot find bounds of current function". This is the only error message I get at any point.
My code is being compiled in GCC with the -g flag (I've tried other types of debugging information using GCC options; none have worked.) I have tried looking through the GDB manual , as well as searching for the answer, and I'm totally stumped. Any help would be amazing.
Thanks!
Well, I got debugging working, but I had to switch emulators. I was able to get GDB working with Qemu, even though I also had problems doing that. To get GDB to connect to the Qemu gdbserver, I had to pass the following option to Qemu: "-gdb tcp::1234,ipv4". Took me forever to figure that out... Debugging works perfectly now!
Googling throws up "This is because when you attached to gdbserver, the process under
debug has not completed the C start-up code" http://www.cygwin.com/ml/gdb/2005-03/msg00237.html... http://www.bravegnu.org/gnu-eprog/c-startup.html describes the process for when you are coding for embedded devices, maybe this will help?
If you find the answer please post here as I'd like to know what the solution to the problem is too.
I don't know why but bochs with gdb-stub enabled seems to be picky with the config options. On some system following options will break it:
--enable-x86-64, --enable-vmx
Related
I am using cubeIDE version 1.8.0 and NucleoF746ZG microcontroller for my project. I have made the codes and when I compile and run they work properly without errors and warnings. But the problem is that when I try to debug, It doesn't work. I mean the debug code uploads to the board but no cursor shows up at the breakpoints. I have tried to make some breakpoints and hault the program at them but no cursor comes to them.
I have opened a trace control tab and it says "Tracing is not supported". I don't know why that happens. The only thing that I know is that after installing the software, It didn't recognized my st-link. It was fixed after replacing the libusb-1.0.dll to a newer version of it. That was the thing that I have changed. But I don't think that it will affect since compiling and running works properly.
If anyone has encountered this issue or if you have any clues about a cause for this matter, please let me know. And request me if you need any more details from my side. I have attached two screenshots for reference.
Thanks and Kind Regards...
Screnshot1
Screenshot2
I am trying to understand how the PE works under windows and so am going down the route of writing a packer.
So I took the address of entry point, that points to _mainCRTStartup and replaced it with a value that points to a "jmp _mainCRTStartup".
When I run it under a debugger my program runs fine but if I just launch the executable without a debugger it crashes and I am unable to attach a debugger post crash, the debugger says that it failed to attach to the crashing process.
I guess my questions would be: Should my approach work? If so what can I try to fix this issue?
Thanks,
Max
It turns out everything worked fine, I forgot to handle an exception in an anti-debug routine that would crash the exe if it wasn't ran in a debugger.
I am trying to port Contiki to LPC1347, just a basic LED blinking program for now. It compiles without any errors but i get a hard fault when i try to run it. On debugging i understood that the hello_world_process thread has an address of 0x636F6C42 (ASCII value considering it to be little endian is Bloc!) which is unrecognized by the mcu. I am using the default initialing libraries of Contiki, i do not understand if there is something wrong with the initialization or any other reason (perhaps something wrong with my linker script or makefile)? Can somebody please help me debug this.
Here is my project's link.
It turns out it was because i was using printf without providing libraries/functions to handle dynamic memory allocation. The program works fine if i do not use printf!
Debugger shows me dissassembler code, while i am trying to step over the instructions of my program.
Using lldb under QtCreator.
Interesting thing is: debugging works fine, if i use it without QtCreator (via terminal)
Small projects seems to debug normally... So I've try to add peaces of my project gradually to small one.
I've found a peace of code, that resulting to crash:
QVector<myClass>::contains();
But if i try to make an empty project only with this realisation, problem disappeared.
I've lost about a week, trying to solve it.
Any ideas, what can go wrong?
EDIT:
Well, QtCreator still using GDB instead of LLDB, that i refer it to...
Looks like bug
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.