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.
Related
I'm trying to set a read watch point in registers.
By reading the user manual. I understood how to set watchpoint in registers
watch [-l|-location] expr [thread thread-id] [mask maskvalue]
Set a watchpoint for an expression. GDB will break when the expression expr is written into by the program and its value changes.
For example: watch $r1. It means GDB will break when the register r1 is written into by the program and its value changes. It works!
But when I use: rwatch $r1, the gdb's reply is "Expression cannot be implemented with read/access watchpoint."
So I want to know how can I set a read watch point in registers. or are There any ways to break when the register is read by the program?
Many Thanks!
So I want to know how can I set a read watch point in registers
I don't believe GDB provides any facility to do so.
When you set a watchpoint on memory location, GDB can implement it very efficiently on platforms that provide special debug registers (e.g. x86_64). The program then runs at full speed, until the location is accessed.
On platforms that don't provide debug registers, GDB has to single-step the program, and compare the value at location with a value it previously recorded. This is very slow (but sometimes useful), and can only work for write watchpoints for obvious reason.
Since registers don't have a "location", when you set a watchpoint on register, GDB performs the same "single step and compare with previous value" dance. And the read watchpoint can't work at all.
What you ask for could be implemented in GDB: single step and examine every instruction -- does it access the named register or not?
But the need for this is very rare, and the implementation complexity is quite high, so I don't think anybody would be willing to actually implement this.
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.
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
How does a debugger set breakpoints if the image is in read-only memory? I know there are hardware breakpoints, but in the debugger I use (OllyDbg) those have to be set specially using a different dialog than normal breakpoints.
Explanation:
Here is a routine in a debugger that is comparing itself to a copy of itself. EDX points to the running image, EBX points to the known good copy of the image. The breakpoint on 4010CE only is reached if there is a mismatch. The character being compared is in the AL register. As you can see the debugger shows EB F6 at 10CE, but this is false. 10CE actually has CC in it, as you can see by looking at the AL register. This is because the debugger has secretely inserted the CC to perform the breakpoint.
The debugger first has to change the memory protection of the page it wants to write to. This can be done with VirtualProtectEx. After that it is able to write with WriteProcessMemory and then set the protection back to the original value.
Let me preface this with a disclaimer that I'm not familiar with your particular toolset.
If you haven't enabled hardware breakpoints, the only remaining breakpoint type is a software breakpoint. These are only hit (on x86 because that's what I'm most familiar with) when you replace the first byte of an instruction with a trap instruction, and will only be routed through the breakpoint mechanism of your OS to your debugger if the correct trap instruction for your OS is used and the debugger has already registered itself with the OS as a debugger for this process. In order to cause the software breakpoint to happen at the correct moment, the trap instruction must be written into your code segment over the first byte of your correct instruction.
The two answers that got here first explain the two scenarios which could get you here (at least, the only two I can think of):
The kernel always has write access everywhere, except for hardware-protected pages (ie on some sort of ROM), which your process' memory is almost certainly not. It has the ability to write the breakpoint instruction regardless of the permissions exposed to the user process being debugged.
The debugger must use some syscall to change the access rights on the memory of the target process before inserting the breakpoint.
Personally, I'm guessing the first thing is happening. The segment permissions are only in place to protect your target process from itself, not from a debugger process or from the kernel. Debugging mechanisms in operating systems pretty regularly violate "normal" permissions to allow the debugger to do whatever it wants to the target process. This, of course, is why some operating systems require you to enter a password before you're allowed to use the debugger in certain scenarios.
However, you can test if it's the second one by attempting to write to the code segment from inside the target process after a breakpoint has been set. If the write succeeds, you know the permissions have been lowered by the OS (to allow the process to be debugged). It would be pretty awkward for the OS to require a debugger to jump through this hoop since it can already insert arbitrary code into the writeable parts of memory and then force a jump to it by generating a stack frame overflow.
The debugger takes advantage of the WriteProcessMemory() function to alter the instruction in place. It'll keep a copy of the instruction. When the bp is hit it will reset the old byte value and set EIP back to the previous instruction so the real instruction can execute.
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.