In lldb command line, I can stop execution of a program (which has no debug symbols) with the --stop-at-entry option by writing:
(lldb) target create /bin/ls
Current executable set to '/bin/ls' (x86_64).
(lldb) process launch --stop-at-entry
Process 22250 launched: '/bin/ls' (x86_64)
Process 22250 stopped
* thread #1: tid = 0xc46fa, 0x00007fff5fc01028 dyld`_dyld_start, stop reason = signal SIGSTOP
frame #0: 0x00007fff5fc01028 dyld`_dyld_start
dyld`_dyld_start:
-> 0x7fff5fc01028: popq %rdi
...
I would prefer, however, to work in the Xcode (5) IDE for lldb. Is the same thing possible there? I can successfully attach to a process through Menu Debug->Attach to Process-> By Process Identifier or Name. If you enter an application name there, lldb will take over that process as soon as it is launched. However, I see no way of stopping execution when the program starts up, i.e. the equivalent of --start-at-entry. Nor do I see a way of entering the respective commands in the lldb window within the IDE, as the application is not launched yet.
Is this possible in the IDE?
Not sure what you are trying to do, but lldb does have a setting to stop on shared library loads:
(lldb) settings set target.process.stop-on-sharedlibrary-events 1
which will cause the program lldb is debugging to stop when a new shared library gets loaded. Not much goes on in the process before the first shared library load, so this will catch it pretty early on.
You can put lldb Xcode-specific setting commands in ~/.lldbinit-Xcode file and they will only apply to lldb instances called from Xcode.
This helps keeping separate settings.
From lldb(1):
FILES
lldb will read settings/aliases/commands from three files at
startup, if they exist.
First, it will read a ~/.lldbinit-debugger command file. If you are
using the lldb command line interface, this is ~/.lldbinit-lldb. If
you are using lldb inside a GUI debugger like Xcode this will be
~/.lldbinit-Xcode.
Entirely doable, at least under Xcode 7.
In an existing Xcode project, create a new schema. In the schema settings, under "Run", specify "Other executable" and choose the one you want. In schema properties, you may also specify command line, working directory, custom environment, etc...
Neither target.process.stop-on-sharedlibrary-events nor settings show target.process.stop-on-exec was having the desired effect for me.
Starting at the very bottom of the stack, I saw _dyld_start, dyldbootstrap::start, and dyld::_main.
Creating a symbolic breakpoint for dyld::_main, specifying the module as dyld, worked for me to get the debugger very early in the startup process.
Trying to set breakpoints on the first two functions did not work for me. I believe that may have something to do with dyld rebasing itself inside that second function: the code isn’t running where the debugger expects it to be in memory until the third frame.
Related
Whenever I try and debug an application with LLDB I can not seem to get a breakpoint set at the entry point of the application.
I have been running br set -n _main and this sets a breakpoint that can be seen when running br list however these breakpoints are never hit.
How do I get LLDB to set a breakpoint at the entry point of my executable?
If you launch your process using:
(lldb) process launch --stop-at-entry -- <Process arguments>
that will stop when your program binary is loaded, but before any code is run. Note, that includes any dyld code - so no shared libraries have been loaded, only the main executable - or any system initializers. So there's generally not much you can do safely at this point. If you want to then stop at the first significant library load, you can do:
(lldb) target.process.stop-on-sharedlibrary-events 1
(lldb) continue
That will run to the first major load event (and stop at all the others if you leave it on.)
If I try to start debugging through the command "Open" of x64dbg, debugging stops without ever starting and a series of missing DLL errors are shown on the screen.
If I just open the program from WIN and THEN I use the attach command by selecting the process, debugging works.
Unfortunately I wanna "investigate" from the moment the program starts and not when it is already started.
How can I solve it ?
You need some anti-anti-debugging plugins (such as ScyllaHide) for x64dbg mentioned in this page to counter anti-debugging attempts and do some patching if needed:
https://github.com/x64dbg/x64dbg/wiki/Plugins
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.
Here's my situation. I have an app installed on my system. It's running. I also have the source for this app and I've built it in XCode and had it generate dSYM files. I attached to the process in XCode. I've been trying to set breakpoints of the form "-[ClassName methodName]" (without the quotes) however none of my breakpoints are getting hit. Do I have to somehow point XCode to my symbol file or something?
I have never debugged using that method, but there is a much easier way. You can simply click on the line number of a code-bearing line and a blue arrow (a breakpoint) will appear there. When the application reaches one of these lines with a breakpoint, execution will pause an allow you to step through the code one line at a time.
I am trying to launch an application via the ShellExecute() API call. This application contains only a main function which does some processing and exits.
Now I have put DebugBreak() in starting of main. When ShellExecute() is called the application is launched successfully but it does not ask for breaking.
How can I debug my application when launched from other application using ShellExecute()?
I am using VC++ .
If DebugBreak() isn't workign for you, try _CrtDbgBreak(). Note that _CrtDbgBreak only works in a debug build.
_CrtDebugBreak definitely works for me to make a launched process break on startup, although I'm pretty sure DebugBreak does also.
Note that both functions will make it look like the process has crashed, since they raise an exception. That is normal and gives you the opportunity to attach a debugger via the crash dialog. (The crash dialog also lets you terminate the process; don't use that, obviously.)
Also note that if you have a catch-all SEH exception handler around your main then the exception raise by DebugBreak & friends will be swallowed up and the app will simply exit without showing the crash dialog or letting you attach to it.
You can't do this with VC++; with WinDbg this is just .childdbg 1 to debug all child processes. With VC++, you can use Image File Execution Options in a pinch - check out http://codereflect.com/2009/09/20/how-to-debug-child-process-using-windbgvisual-studio/ for more info. Really though, if you've got the time to learn WinDbg, it's much better at this.
you can try this, it's ok in xp system.
app.exe is your application name,
-s1...-s3 is command line arguments.
HINSTANCE hRet = ShellExecute(NULL, L"open", L"vsjitdebugger.exe", L" app.exe -s1 a1 -s2 a2 a3 -s3", szExePath, SW_SHOW);
There is now a Microsoft Child Process Debugging Power Tool.
The method I use for things like this is to embed some interactive code, which you can either delete afterwards, comment out or conditionally enable. In a few cases we have this code enabled by querying an environment variable which is set by the tool that launches the main application. This allows me to click a check box, hit launch and have the breakpoint dialog in seconds.
if (MessageBox(NULL,
_T("Attach the debugger now, then choose Yes to hit a breakpoint"),
_T("Attach Debugger"),
MB_YESNO) == IDYES)
__debugbreak();
This gives you the ability to attach the debugger when the dialog box appears and the option to hit a breakpoint or not. My earlier versions didn't give me the option and after a while I realised some of the time I wanted the breakpoint, and some of the time I didn't.