LLDB command jump lets me resume program execution at a different position from where it has stopped, but it seems to be restricted to addresses inside the current function:
(lldb) jump CLI.cpp:15
error: CLI.cpp:15 is outside the current function.
I'm curious about that, since this restriction is not documented in lldb's help, and the syntax jump <file>:<line> somehow indicates that one could use arbitrary entry points:
(lldb) help jump
('_regexp-jump') Set the program counter to a new address. Expects 'raw'
input (see 'help raw-input'.)
Syntax:
_regexp-jump <line>
_regexp-jump +<line-offset> | -<line-offset>
_regexp-jump <file>:<line>
_regexp-jump *<addr>
'jump' is an abbreviation for '_regexp-jump'
I'm aware that resuming in a different frame/stack may bring the program into an inconsistent state with "wonderful" side effects.
How can I jump to lines outside the current function in lldb (ignoring possible side effects)?
jump is a wrapper command that packages up some common uses of the underlying thread jump into a compact form. That's what all the _regex- commands are in lldb. Do:
(lldb) help command regex
if you want more details on this regex commands, and of course
(lldb) help thread jump
for everything you can do with that command.
The wrapper doesn't have an affordance to allow jumping outside the current function because that is definitely NOT a safe operation, so the default is to assume you made a mistake in typing the line or file name...
The underlying command does have a --force option that allows you to move the pc out of the current function.
Related
I am currently writing a debugger for a script virtual machine.
The compiler for the scripts generates debug information, such as function entry points, variable scopes, names, instruction to line mappings, etc.
However, and have run into an issue with step-over.
Right now, I have the following:
1. Look up the current IP
2. Get the source line from that
3. Get the next (valid) source line
4. Get the IP where the next valid source line starts
5. Set a temporary breakpoint at that instruction
or: if the next source line no longer belongs to the same function, set the temp breakpoint at the next valid source line after return address.
So far this works well. However, I seem to be having problems with jumps.
For example, take the following code:
n = 5; // Line A
if(n == 5) // Line B
{
foo(); // Line C
}
else
{
bar(); // Line D
--n;
}
Given this code, if I'm on line B and choose to step-over, the IP determined for the breakpoint will be on line C. If, however, the conditional jump evaluates to false, it should be placed on line D. Because of this, the step-over wouldn't halt at the expected location (or rather, it wouldn't halt at all).
There seems to be little information on debugger implementation of this specific issue out there. However, I found this. While this is for a native debugger on Windows, the theory still holds true.
It seems though that the author has not considered this issue, either, in section "Implementing Step-Over" as he says:
1. The UI-threads calls CDebuggerCore::ResumeDebugging with EResumeFlag set to StepOver.
This tells the debugger thread (having the debugger-loop) to put IBP on next line.
2. The debugger-thread locates next executable line and address (0x41141e), it places an IBP on that location.
3. It calls then ContinueDebugEvent, which tells the OS to continue running debuggee.
4. The BP is now hit, it passes through EXCEPTION_BREAKPOINT and reaches at EXCEPTION_SINGLE_STEP. Both these steps are same, including instruction reversal, EIP reduction etc.
5. It again calls HaltDebugging, which in turn, awaits user input.
Again:
The debugger-thread locates next executable line and address (0x41141e), it places an IBP on that location.
This statement does not seem to hold true in cases where jumps are involved, though.
Has anyone encountered this problem before? If so, do you have any tips on how to tackle this?
Since this thread comes in Google first when searching for "debugger implement step over". I'll share my experiences regarding the x86 architecture.
You start first by implementing step into: This is basically single stepping on the instructions and checking whether the line corresponding to the current EIP changes. (You use either the DIA SDK or the read the dwarf debug data to find out the current line for an EIP).
In the case of step over: before single stepping to the next instruction, you'll need to check if the current instruction is a CALL instuction. If it's a CALL instruction then put a temporary breakpoint on the instruction following it and continue execution till the execution stops (then remove it). In this case you effectively stepped over function calls literally in the assembly level and so in the source too.
No need to manage stack frames (unless you'll need to deal with single line recursive functions). This analogy can be applied to other architectures as well.
Ok, so since this seems to be a bit of black magic, in this particular case the most intelligent thing was to enumerate the instruction where the next line starts (or the instruction stream ends + 1), and then run that many instructions before halting again.
The only gotcha was that I have to keep track of the stack frame in case CALL is executed; those instructions should run without counting in case of step-over.
I've tried to set breakpoint on every function that makes any sense but program exit before reaching any of those. Is there a way to make program run in step-by-step mode from the start so I can see what's going on?
I'm trying to debug /usr/bin/id if it's important (we have custom plugin for it and it's misbehaved)
P.S. Start command doesn't work for me here(it should be a comment, but I don't have enough rep for it)
Get the program entry point address and insert a breakpoint at that address.
One way to do this is to do info files which gives you for example "Entry point: 0x4045a4". Then do "break *0x4045a4". After run-ning program, it will immediately stop.
From here on you can use single stepping instructions (like step or stepi) to proceed.
You did not tell what system you are trying to debug. If code is in read-only memory you may need to use hardware breakpoints (hbreak) if they are supported by that system.
Use start command
The ‘start’ command does the equivalent of setting a temporary breakpoint at the beginning of the main procedure and then invoking the ‘run’ command.
e.g.
a program with debug info main, and usage like this: main arg1 arg2
gdb main
(gdb) start arg1 arg2
Use starti. Unlike start this stops at the actual first instruction, not at main().
You can type record full right after running the program. This will record all instructions and make them possible for replaying/going back.
For main function, you'd need to type this before reaching the breakpoint so you can set an earlier one by break _start -> _start is a function always called before the standard main function. (apparently applies only to the gcc compiler or similar)
Then continue to main breakpoint and do reverse-stepi to go exactly one instruction back
For more info about recording look here: link
list commands prints a set of lines, but I need one single line, where I am and where an error has probably occurred.
The 'frame' command will give you what you are looking for. (This can be abbreviated just 'f'). Here is an example:
(gdb) frame
\#0 zmq::xsub_t::xrecv (this=0x617180, msg_=0x7ffff00008e0) at xsub.cpp:139
139 int rc = fq.recv (msg_);
(gdb)
Without an argument, 'frame' just tells you where you are at (with an argument it changes the frame). More information on the frame command can be found here.
Command where or frame can be used. where command will give more info with the function name
I do get the same information while debugging. Though not while I am checking the stacktrace. Most probably you would have used the optimization flag I think. Check this link - something related.
Try compiling with -g3 remove any optimization flag.
Then it might work.
HTH!
Keep in mind that gdb is a powerful command -capable of low level instructions- so is tied to assembly concepts.
What you are looking for is called de instruction pointer, i.e:
The instruction pointer register points to the memory address which the processor will next attempt to execute. The instruction pointer is called ip in 16-bit mode, eip in 32-bit mode,and rip in 64-bit mode.
more detail here
all registers available on gdb execution can be shown with:
(gdb) info registers
with it you can find which mode your program is running (looking which of these registers exist)
then (here using most common register rip nowadays, replace with eip or very rarely ip if needed):
(gdb)info line *$rip
will show you line number and file source
(gdb) list *$rip
will show you that line with a few before and after
but probably
(gdb) frame
should be enough in many cases.
All the answers above are correct, What I prefer is to use tui mode (ctrl+X A or 'tui enable') which shows your location and the function in a separate window which is very helpful for the users.
Hope that helps too.
I apologize for the likely trivial question but I am running into a wall as Google gives me the same non-applicable answers over and over.
I am trying to set a breakpoint in LLDB. After reading the documentation, the options available to me are to either stop on a certain line in the source or on a certain symbol.
What I want to do is set a breakpoint on a certain memory location.
Not read-or-write to that memory location either but simply breaking when the instruction at that location is about to be executed.
In Pseudocode:
break 0x00010000
breaks when EIP points to 0x00010000.
How can I do this?
breakpoint set has an address option; you would type help breakpoint set to see all of them. For your specific example,
(lldb) br s -a 0x10000
(You can always use shorter versions of command names in lldb that are unambiguous so typing out breakpoint set isn't necessary)
The alternative is to use "process launch --stop-at-entry ...". This will allow you to set breakpoints after the program is launched and then "continue" will let you stop on your first breakpoint. Interestingly (testing in Ubuntu) using --stop-at-entry takes a lot longer to start (~3 seconds). I need to use this on OS X and maybe it will be quicker there.
Can I, using an address found in a map file, use windbg to alter a variable in memory while the app is running?
I'm really interested in turning on/off functionality in run-time maybe with a variable.
How would you do this? Does it require breaking the app through the debugger?
If you have the address, you can use the any of the e* (Enter Value) commands.
You can attach to any running process if you know the process id, or you can launch the exe directly with cdb. You do have to break the process to make any modifications. In CDB, you can use Ctrl+C, and the it will inject a DebugBreak into the process, you can then look at the stack, threads, and memory.
I just did it. Assuming you got the symbos mapped, and are in a breakpoint where you can see a variable, you just do this - assuming "myvar" is an integer:
?? myvar
[[ this shows the current contents ]]
?? myvar=55
[[ this will change the value of myvar to 55]]
?? myvar
[[ this will show the updated contents of my var - which is 55 ]]
g
[[ your program will now run, and the next read of myvar will produce 55 ]]
You can set a breakpoint that is only hit once and edit a value and continue execution.
Something like:
bp /1 012ABCDEF "myVar=42;g"
replace the above with your address value and your variable name.
I'm not sure what exactly you trying to achieve, but debugger should be activated on some event (exception, break point or something), after it's activated, for example you can have a thread that create an exception and after get control back check the variable.
In debugger you can set a break point with command, see this guide, what will change the parameter.
I hope that this answer your question, if not please clarify the question.
In case of break point with command the application will be break and will continue execution without human intervention, i don't know any way how debugger can do something without application stops execution.
Just a thought, are you sure you need debugger for this? Can't you just use registry for that and use this to get notification about registry change.
You can definately do that. Either break on a function and edit it in the locals window. Or use e commands to edit values. Check out the windbg help for more on it.