I compile such code by GCC (v7.1.0) (command line below).
int func()
{
return 0x1234;
}
int main()
{
func();
return 0;
}
gcc .\001_simpleMain.c -O0 -m64 -g
After compilation I run WinDbg (10.0), open executable (Ctrl+E), program is loading. Breakpoint is hit on start process everthing is ok.
After it I want to open source code (Ctrl+O) and try to put breakpoint inside func method.
WinDlg tells me:
*** ERROR: Module load completed but symbols could not be loaded for G:\Examples\Gcc\a.exe
Why it is not working? Should I change compilation param? MY CPU is AMD64
Since you're using Windows with WinDbg you need the proprietary PDB files, which contain the debugging information for debugger tools that come from Microsoft.
GCC will generate debugging information that can be used by the gdb debugger (well known in Linux) for example.
gcc -g:
Produce debugging information in the operating system’s native format (stabs, COFF, XCOFF, or DWARF). GDB can work with this debugging information.
If you are using MinGW or Cygwin already you can use gdb from there because it's available in the MinGW/Cygwin environment. If not there are several gdb implemenations for Windows available.
Once you have built debugging files according to #Andre Kampling's instructions, you'll first need to convert them into PDB format. But even then, WinDbg will likely still not find them.
The executable has some data which points to the PDB file. Since you built in on Linux, that will be a Linux path which is not available on your Windows system.
Therefore, you need to set up your symbol path correctly so that WinDbg knows where you put them.
Basically you'll need
0:000> .symfix c:\symbols
for the Microsoft symbols and
0:000> .sympath+ c:\path\to\your\symbols
and then instruct WinDbg to load them again
0:000> .reload /f
0:000> ld*
Related
I have a C library which is created with
cc -fPIC -g -O3 -c -o obj/my_lib.o my_lib.c
g++ -shared -Wl,-soname,libmy_lib.so.1 obj/my_lib.o -o libmy_lib.so.1.8.0
This library is packaged into debian packages with dpkg-buildpackage producing libmy_lib1-1.deb, libmy_lib1-dev-1.deb, and libmy_lib1-dbgsym-1.ddeb. Installing all of those packages, I can then compile/link a simple test program that calls into the library. This works. Running the test program works.
However, when I run GDB on the test program (on the same computer), I see
gdb$ break main
Breakpoint 1 at 0x87e: file test.c, line 10.
gdb$ info sharedlibrary
No shared libraries loaded at this time.
gdb$ r
Starting program: /tmp/a.out
Breakpoint 1, main () at test.c:10
10 my_library_func();
gdb$ info sharedlibrary
From To Syms Read Shared Object Library
0x00007ffff7dd5f10 0x00007ffff7df4b20 Yes /lib64/ld-linux-x86-64.so.2
0x00007ffff7bac9a0 0x00007ffff7bad438 Yes /usr/lib/x86_64-linux-gnu/libmy_lib.so.1
0x00007ffff74532d0 0x00007ffff75cbc3c Yes /lib/x86_64-linux-gnu/libc.so.6
0x00007ffff709fa80 0x00007ffff715e2f5 Yes /lib/x86_64-linux-gnu/libm.so.6
0x00007ffff6e7eac0 0x00007ffff6e8f36d Yes /lib/x86_64-linux-gnu/libgcc_s.so.1
(*): Shared library is missing debugging information.
gdb$ s
my_library_func () at my_lib.c:299
299 my_lib.c: No such file or directory.
As you can see, GDB knows about the debug symbols for the library. However, it does not know about the source file for the library. How should I running GDB to it can resolve the C source code?
You need to also tell gdb where the source files are. Which means you also need the source files, not just the debugging symbols.
It's important that the sources you download are the actual ones used to compile the library, because debugging information only contains filename and line number. If you give gdb a file where the line numbers don't correspond (a different version, for example), the source lines printed by gdb will be very confusing. It has no way to know they are wrong. You should be able to use the src deb with the same version number as the library debs.
Once you have the source files, tell gdb where to look for them with
directory /path/to/source/files
You can specify several paths. Read help directory inside gdb.
Since you'll need to do this often, put that line into a gdbinit file. You'll probably want to use .gdbinit in your current directory, but .gdbinit in your home directory might also be a possibility. Gdb uses both.
If you're working with a library whose source is spread over a subdirectory tree, you might find it useful to set a substitution path:
set substitute-path /your/file/path /original/file/path
Again, more help is available with help set substitute-path.
GDB searches a number of default directory paths to locate the specified sourcefile. You can add paths using the directory command: https://sourceware.org/gdb/current/onlinedocs/gdb/Source-Path.html
I am having trouble getting the debugger to work properly when setting up clang on my Windows 10 machine. Compilation seems to work OK, at least for the simple "hello, world" program I tried. However, when I try to run the lldb or gdb debuggers on this test program (or any other program I tried), it does not recognize function names.
Here's my C program code:
#include <stdio.h>
int main(void) {
puts("Hello, world!");
return 0;
}
Nothing too spectacular here, I know. I'm compiling with the following command:
> clang -g -O0 hello.c -o hello.exe
I then try to run the debugger:
> lldb hello
(lldb) target create "hello"
Current executable set to 'hello' (x86_64).
(lldb) b main
Breakpoint 1: no locations (pending).
WARNING: Unable to resolve breakpoint to any actual locations.
(lldb) r
Process 12156 launched: 'C:\Users\********\Projects\clang-test\hello.exe' (x86_64)
Process 12156 exited with status = 0 (0x00000000)
(lldb)
Apparently the symbol "main" was not recognized, and the program did not halt at the start of the "main" function but ran to completion (in a different console window, hence no program output here).
How do I get debugging symbols to work? In a different stackoverflow answer I found that adding compiler options "-g -O0" should do the trick, but as you can see that does not solve the problem for me. I also found a different stackoverflow answer about how to set up debugging if the code is not in the same directory as the executable, but that is not relevant to my case: the current working directory is the same as the directory with the code and executable in them.
Some version information:
> clang --version
clang version 9.0.0 (tags/RELEASE_900/final)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Program Files\LLVM\bin
> lldb --version
lldb version 9.0.0
The "-g -O0" options you provided should indeed let the debugger know all the symbols it needs from the executable.
Therefore, I suspect the problem is elsewhere, perhaps with your terminal, or your version/implementation of LLDB.
Are you using the windows cmd.exe commandline ? or something else, like Powershell ?
I've never managed to get debuggers working properly in those environments, but it was much easier with Cygwin, which is a bash shell for windows (it creates a "simulated" linux environment within its install folder, so you have all the /usr,/bin,/etc folders a bash shell needs)
This way you can actually use gdb the way you would on a UNIX system.
If the above method sounds like more of a hassle than a time-gain, then yeah I would recommend another debugger altogether, like the Visual Studio debugger.
In fact, maybe a memory-analysis tool like Dr.Memory can give you what you need
Currently I am using Clion IDE plus latest version of Open Watcom v2 windows 32 bit compiler to develop some 16 bit MS-DOS application. The problem I have is I don't see all required debugging information when using watcom windows debugger (wdw.exe).
Being specific, I see global variables, global and any other types of functions, even those imported from asm files. But well, local variables list is empty all the time. But more importantly - the only c-code I can see is little test.c file which contains only main() function and nothing else except for includes.
What do I need to do to finally get c-level debugging for whole project? What am I missing?
I would be grateful for any help.
All source files is located in one directory, so, they all should be visible to debugger. But it sees only main c file.
Of course I am compiling with -d2 switch, as well as -hw. DEBUG WATCOM ALL is also presented in linker config file before any FILE directives. Reading manuals to compiler and linker... Well, it's nice that I've found many interesting things in manuals, but nothing helped with exactly that issue so far :)
List of compiler switches I currently using:
WCC.EXE:
CALL WCC.EXE -dTEST -bt=dos -0 -za99 -wx -we -mc -zp2 -hw -d2
%SRC_FULL_NAME%
WLINK:
CALL WLINK.EXE #..\CC.LK
CC.LK:
SYSTEM DOS
DEBUG WATCOM ALL
FILE TEST.OBJ
FILE LUTILS.OBJ
FILE LGL.OBJ
NAME TEST.EXE
OPTION ELIMINATE
...
I have an application that I compile for 32-bit DOS/DPMI target (with DOS32/A extender) using OpenWatcom classic (1.9 - latest stable release). If the program crashes on a bad memory access, I get the CS:EIP of the faulting instruction. How can I map this to assembly code / source line number? (Note: I am using the Windows version of OpenWatcom under Wine (running in Linux) and then run the executable in DosBox.)
With GCC/binutils I'd compile with -ggdb and then use objdump -DS on the executable to get both assembly and source view. Any OpenWatcom equivalent? Or, maybe, an interactive debugger that can do the same? I tried using wdis, but that only works on object files, not on executables. Since with the object file I cannot tell where it will be relocated to, it's useless. Or maybe there's at least a way to produce the symbol map for the executable?
Note that DOSBox does not fully emulate the CPU, especially with regards to protected-mode debugging support. So if you want to debug a DOS protected-mode executable you need to use a VM or some other emulator.
That said, you can do the following.
Make sure you have these environment variables set (assuming that the development tools path is C:\WATCOM):
SET PATH=C:\WATCOM\BINW;%PATH%
SET INCLUDE=C:\WATCOM\H
SET WATCOM=C:\WATCOM
SET EDPATH=C:\WATCOM\EDDAT
SET WD=/TR#RSI/SWAP
WD is the one that specifies the default options for DOS Watcom Debugger:
the /TR#RSI flag specifies that the executable uses the DOS/4G DOS extender
/SWAP specifies that video memory swap is done using a single page, it is mandatory if you are developing a graphics application.
As far as I know WD does not support the DOS32/A DOS extender, so you may decide to use DOS/4G.
Be sure to specify the -d2 flag for the compiler (wcc386) and debug all for the linker (wlink).
Example makefile:
LINK_FLAGS_DBG = debug all SYS dos4g op m op maxe=25 op q op symf
CC = wcc386
CC_FLAGS_DBG = -i=C:\WATCOM\H -w4 -e25 -zq -otexan -d2 -5s -bt=dos -mf
OBJS = test.obj
test.exe : $(OBJS) test.lnk
wlink $(LINK_FLAGS_DBG) #$^*
test.lnk : $(OBJS)
echo NAME $^& >$^#
echo DEBUG all >>>>$^#
for %i in ($(OBJS)) do echo FILE %i >>$^#
clean :
del *.obj
del *.exe
del *.lnk
del *.map
del *.sym
.c.obj : .AUTODEPEND
$(CC) $[* $(CC_FLAGS_DBG)
test.c file:
#include <stdio.h>
void main(int argc, char *argv[]) {
int test = 1234;
printf("Hello world!\ntest is %d", test);
}
Build the executable (and symbols and map files) with:
wmake
Launch the Watcom DOS Debugger with:
wd test
You should be on this screen:
From here you can debug your program interactively, like with modern debuggers.
As a side notes:
refer to the documentation, although I only installed the DOS tools, it is very accurate and complete
note that knowing the address of the faulting instruction is not the same as knowing why that instruction crashed the program, which is why I invited you to use (maybe temporarily) DOS/4G and Watcom Debugger.
I have compiled my own glibc, which produced libc.so. I loaded the libc.so file in gdb by doing gdb -q ./libc.so. However, when I try to find the location of a function by doing list function_name, I get the error message, No line number known for function_name. Note that I use the -g flag for compiling glibc. How can I solve this problem?
Can you even debug a .so by itself? What I would try is to do is gdb executable_using_my_libc. Then this should load glibc and so on.