I compiled a debugging version program using gcc for arm. I debug it using gdb7.3. I can set normal break points, but I can't execute "next" command. It prompt "Could not insert single-step breakpoint at 0x?????".
If you need more detail information, I will append it.
Thanks.
Related
So I am using Qt Creator with LLDB as debugger.
To debug stuff I add breakpoints and when the code hits the breakpoint it stops and I can see the back trace and all and that's useful. However, sometimes I don't want to stop and I am only interested in whether the breakpoint is hit, or I want to inspect a value there.
I usually do this with adding debugging messages but that generally takes a lot of time to recompile the project and rerun the scenario.
I'm wondering is there a better way to do this, using a debugger, preferably LLDB.
All the break set commands take a --auto-continue option (one-letter: -G) that will instruct lldb to continue after stopping for the breakpoint (and running any of its commands).
You can run lldb commands when a breakpoint is hit (e.g. to do a backtrace or print some locals) using the break command add command or by adding any number of -C options to the break set command. You can also add a Python implemented callback to the breakpoint as described here:
https://lldb.llvm.org/use/python-reference.html#running-a-python-script-when-a-breakpoint-gets-hit
if you need to do something fancier to gather your report when you hit the breakpoint.
If you want to edit currently active break point you can do the following:
breakpoint modify <break_point_id> -G true
I have just started using KDbg and am having a hard time finding the answer to my question. I open a file in KDbg (I opened an executable written in assembly), there is a pop up that says
GDB: Reading symbols from /home/myputer/Desktop/ASMdirectory/chapter5/eatsyscall/eatsyscall...done.
How do I get the option to run the program in the debugger and add breakpoints and etc. It doesn't allow me to click the button to run the program or add any breakpoints, is there an issue here? Am I missing a step? Thanks in advance. BTW I'm using Linux(Ubuntu) and NASM for my assembler.
What are the versions of software you are running?
For example I am running
Ubuntu 12.04,
kdbg 2.5.0 (KDE Development Platform 4.8.5),
gdb 7.4-2012.04,
nasm 2.09.10
You are using Duntemann's book, yes?
I am assuming you changed SECTION .txt to SECTION .text because
when GDB attempts to read symbols it reports "done" instead of "Can't find any code sections in symbol file"
I would recommend using gdb directly instead of kdbg. I do not know of a way to get kdbg to show disassembled code or list (or how to send any gdb commands directly). I think the best that can be done is:
Run kdbg
Open the executable
Switch to the Breakpoints tab
Enter "_start" (which I believe is the only visible symbol you have) in the edit box.
Hit the "Add Breakpoint" button
Hit the "Run" button
Execution should have broken at _start
Switch to the Registers tab
Hit the "Step into by instruction" button to walk through your code
Kdbg does not seem to be able to restart execution. It seems the program must be killed then run again.
My workflow follows.
Configure the symbol file path and source code file path for WinDbg.
Open one source code file to be debugged later.
Press F9 and try to set breakpoint in the source code.
WinDbg pops up an error dialog, saying 'Debuggee must be stopped before breakpoints can be modified.'
Who can tell me why? My WinDbg version is 6.11.0001.404 (X86), Windows XP 64-bit. I am debugging a dll from within very complicated runtime system.
I wrote a simple exe and click to open it. Immediately after opening it, I open the source code file and set one breakpoint. It works in this case!
The hint is in the error, "Debuggee must be stopped before breakpoints can be modified". You have to break into the target process with Debug->Break before WinDBG will let you set a breakpoint. When you launch an EXE under WinDBG is starts off broken in, so you can set the breakpoint.
-scott
Is there a way to follow a program's execution through DLL code in hex?
For example, I want to see what sections have just been read when I press a button. It has to work for x64 DLL's.
Thanks!
Yes you load the process into debugger and single step it.
Load the project in visual studio.
Press 'Play' or F5 to start the program in the debugger.
You will need to eventually halt execution sometime so you can start stepping through code or assembly code. You can do this by inserting a breakpoint, or breaking the execution by hitting the break command in the visual studio IDE.
Once halted, you can right click in the code view window, and select "Show Disassembly". Then it will show you the machine instructions.
Also in the watch window in the visual studio debugger, the right click pop up menu has an option to display all variables as hexidecimal. I'm beginning to prefer hex myself lately, because I can see invalid memory patterns easier.
You can use the tool at http://ircdb.org to log function calls arbitrary DLLs.
It's name is SocketSpy, because initially it was created for tracing winsock.dll only, but it does allow you to trace other dlls.
From http://fixunix.com/programmer/95098-tracing-library-dll-calls-win32.html
Use Option->Default Break Point List
Menu to add or remove soft breakpoints
from attached DLLs. Put soft
breakpoints only at function you need
to maximize execution time.
Soft breakpoint means that socketspy
does not stop at this breakpoint, only
log breakpoint information. Hard
breakpoint means that socketspy DOES
STOP at this breakpoint, and
Breakpoint dialog is opened. Specify
what calls should be captured ALL,
FROM EXE FILE or from DLLs (Combobox).
Specify log file File->Open Log File
menu if you want to save function
DLLs' calls into the text file, enable
logging (check box).
Then select a new or already action
process (Select Process button). The
tool can be used in NT/2000/XP only
Alternatively, there is StraceNT, which can trace arbitrary Dlls. It is available for free from http://www.intellectualheaven.com/default.asp?BH=projects&H=strace.htm
I've not used it, but I once stumble upon an Intel tool, which samples the context of the Instruction Pointer, and is able to use symbol files to convert IP to an actual function name... VTune maybe?
I guess there might be other such tools
UPDATE: aka. "statistical profilers"...
Debugging using IDE does not show you the assembly language equivalent of the execution of an IL instruction. You need to write your own hooks to a proper disassembler.
I am using the debugger (vs2008).
Once I've stepped into a catch statement, I would like to know if there is any way to set the execution cursor back to the beginning of the try.
Just dragging it there doesn't seem to work, is there some setting I need to change?
Example:
try
{
//Want the cursor back here
}
catch
{
//some code, cursor is here...
}
Apparently it depends which flavor of .NET runtime you are using. At the time I first wrote this, it worked fine for me when I tried it, but I was using my work PC, with a 32-bit OS installed.
I'm using this code snippet to test:
try
{
throw new Exception();
}
catch
{
Console.WriteLine("Error"); // Breakpoint here
}
You can't set the cursor on the try line. It will be on the line following immediately after it (the opening of the block statement).
Dragging the cursor to that line or the try line works fine for me when I compile my .NET program for x86. It will also work if you're running a 32-bit OS. However, when you're on a 64-bit environment and compile for Any CPU or x64, you will get the following error message:
Since this is for debugging purposes only, a possible workaround for you would be to compile for x86, so the 32-bit runtime will be used. Go to the Build menu and choose Configuration Manager. Under Platform, select x86 or New... if it's not currently in the list. In the latter case, you'll get a new dialog. Pick the options as shown below and click OK:
If I right click and do "set next statement" then I get the following error dialog:
Unable to set the next statement to this location. The attempt to unwind the callstack failed.
Unwinding is not possible in the following scenarios:
Debugging was started via Just-In-Time debugging.
An unwind is in progress.
A System.StackOverflowException or System.Threading.ThreadAbortException exception has been thrown.
By elimination the reason why you cant move the cursor (The same as setting the next statement) must be #2.