I have code blocks 13.12 with borland 5.5 and mingw debugger. Everytime I debug, it debugs it completely without stopping at breakpoints or cursor (when pressed run to cursor). The debug log is:
Building to ensure sources are up-to-date
Selecting target:
Debug
Adding source dir: G:\Copy_string\
Adding source dir: G:\Copy_string\
Adding file: G:\Copy_string\bin\Debug\Copy_string.exe
Changing directory to: G:/Copy_string/.
Set variable: PATH=.;C:\Borland\BCC55\Bin;C:\Borland\BCC55;C:\Program Files\Intel\iCLS
Client;C:\Windows\System32;C:\Windows;C:\Windows\System32\wbem;C:\Windows\System32\
WindowsPowerShell\v1.0;C:\Program Files\Intel\OpenCL SDK\2.0\bin\x86;C:\Program
Files\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files\Intel\Intel(R) Management
Engine Components\IPT
[debug]Command-line: C:\CodeBlocks\MinGW\bin\gdb.exe -nx -fullname -quiet -args
G:/Copy_string/bin/Debug/Copy_string.exe
[debug]Working dir : G:\Copy_string
Starting debugger: C:\CodeBlocks\MinGW\bin\gdb.exe -nx -fullname -quiet -args
G:/Copy_string/bin/Debug/Copy_string.exe
done
[debug]> set prompt >>>>>>cb_gdb:
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints
[debug]Reading symbols from G:\Copy_string\bin\Debug\Copy_string.exe...(no debugging symbols found)...done.
[debug](gdb) >>>>>>cb_gdb:
[debug]> show version
Reading symbols from G:\Copy_string\bin\Debug\Copy_string.exe...(no debugging symbols found)...done.
[debug]GNU gdb (GDB) 7.5
[debug]Copyright (C) 2012 Free Software Foundation, Inc.
[debug]License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
[debug]This is free software: you are free to change and redistribute it.
[debug]There is NO WARRANTY, to the extent permitted by law. Type "show copying"
[debug]and "show warranty" for details.
[debug]This GDB was configured as "i686-pc-mingw32".
[debug]For bug reporting instructions, please see:
[debug]<http://www.gnu.org/software/gdb/bugs/>.
[debug]>>>>>>cb_gdb:
[debug]> set confirm off
Debugger name and version: GNU gdb (GDB) 7.5
[debug]>>>>>>cb_gdb:
[debug]> set width 0
[debug]>>>>>>cb_gdb:
[debug]> set height 0
[debug]>>>>>>cb_gdb:
[debug]> set breakpoint pending on
[debug]>>>>>>cb_gdb:
[debug]> set print asm-demangle on
[debug]>>>>>>cb_gdb:
[debug]> set unwindonsignal on
[debug]>>>>>>cb_gdb:
[debug]> set print elements 0
[debug]>>>>>>cb_gdb:
[debug]> set new-console on
[debug]>>>>>>cb_gdb:
[debug]> set disassembly-flavor att
[debug]>>>>>>cb_gdb:
[debug]> catch throw
[debug]Function "__cxa_throw" not defined.
[debug]Catchpoint 1 (throw)
[debug]>>>>>>cb_gdb:
[debug]> source C:\CodeBlocks\share\codeblocks/scripts/stl-views-1.0.3.gdb
[debug]>>>>>>cb_gdb:
[debug]> set follow-fork-mode child
[debug]>>>>>>cb_gdb:
[debug]> directory G:/Copy_string/
[debug]Source directories searched: G:/Copy_string;$cdir;$cwd
[debug]>>>>>>cb_gdb:
[debug]> run
[debug]Starting program: G:\Copy_string\bin\Debug\Copy_string.exe
Child process PID: 3596
[debug][New Thread 3596.0x4e4]
[debug][Inferior 1 (process 3596) exited with code 020325214]
[debug]>>>>>>cb_gdb:
[Inferior 1 (process 3596) exited with code 020325214]
[debug]> quit
Debugger finished with status 0
`
Make sure that 'Build->Select target' is [X] Debug. Then open the source program you want to debug and click on the line where you want the debugger to stop.
Lastly, use [Right Click]+[Run to cursor]. A yellow arrow should show besides the line number on your source code window.
This worked with me:
choose debugger from setting.
select default
change the executable path to
C:\msys64\mingw64\bin\gdb.exe
Related
This is a follow-up question that originates from the answer from thiefmaster to this question: gdb input redirection using cygwin
I am a beginner, so kindly pardon my ignorance.
I want to know how to redirect input to gdb using a text file while using a command-line argument? if you can elaborate the answer, it would be better. When should I enter command-line argument -f filename. i.e.
i tried following but it didn't work
gcc -g testing3.c -o testing 3.exe
gdb testing3.exe
b main // to ensure it breaks on main
run -f userinput.txt
I have installed cygwin for compiling, running and debugging c
programs. (CYGWIN_NT-10.0-18363 version 3.3.3-341.x86_64)
My userinput.txt is also saved in the same location as the pwd of gdb
I have tried all the following ways, but none seem to work:
attempt#1
gdb ./testing3.exe -i userinput.txt
output of gdb is
Interpretor 'userinput.txt' unrecognized
attempt#2
gdb -ex 'set args < userinput.txt' ./exercise5-7.exe
gdb output is as follows: basically, it still asks for input from STDIN interactively rather than reading from userinput.txt
51009396#NHQ-GF-51009396 /cygdrive/d/Let us C/Practice
$ gdb -ex 'set args < userinput.txt' ./exercise5-7.exe
GNU gdb (GDB) (Cygwin 10.2-1) 10.2
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-cygwin".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./exercise5-7.exe...
(gdb) r
Starting program: /cygdrive/d/Let us C/Practice/exercise5-7.exe < userinput.txt
[New Thread 28036.0x1a48]
[New Thread 28036.0x6cbc]
[New Thread 28036.0x5ab0]
readlines: user input would start shortly
[New Thread 28036.0x4f74]
i am
manually
typing the
input
writelines
i am
manually
typing the
input
[Thread 28036.0x1a48 exited with code 0]
[Thread 28036.0x6cbc exited with code 0]
[Thread 28036.0x6e30 exited with code 0]
[Thread 28036.0x4f74 exited with code 0]
[Inferior 1 (process 28036) exited normally]
(gdb)
attempt#3
gdb ./testing3.exe
b main
r
call dup2(open("userinput.txt",0),0)
gdb outputs
'open' has unknown return type; cast the call to its declared return type
Edit #2: basis comments from matzeri and ssbssa
I tried the suggestion. following is the gdb output:
51009396#NHQ-GF-51009396 /cygdrive/d/Let us C/Practice
$ cat userinput.txt
God
is
great
51009396#NHQ-GF-51009396 /cygdrive/d/Let us C/Practice
$ gdb exercise5-7.exe
GNU gdb (GDB) (Cygwin 10.2-1) 10.2
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-cygwin".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from exercise5-7.exe...
(gdb) b main
Breakpoint 1 at 0x100401090: file exercise5-7.c, line 12.
(gdb) delete 1
(gdb) i b
No breakpoints or watchpoints.
(gdb) run < userinput.txt
Starting program: /cygdrive/d/Let us C/Practice/exercise5-7.exe < userinput.txt
[New Thread 22400.0x70d4]
[New Thread 22400.0x70e0]
[New Thread 22400.0x719c]
readlines: user input would start shortly
[New Thread 22400.0x1bec]
God
is still
great
writelines
God
is still
great
[Thread 22400.0x70f0 exited with code 0]
[Thread 22400.0x70e0 exited with code 0]
[Thread 22400.0x70d4 exited with code 0]
[Thread 22400.0x1bec exited with code 0]
[Inferior 1 (process 22400) exited normally]
(gdb)
it basically asks for user input from the STDIN and ignores the userinput.txt file. the messages readlines: use input would start shortly and writelines are my print statements in the code.
I am trying to create breakpoints and debug gem5 using gdb. I referred to http://www.gem5.org/Debugger_Based_Debugging.
As in the official documentation in the above link, I tried `call schedBreak() but it doesn't work. the following are the full commands:
➜ test-gem5-x86 git:(master) ✗ gdb --args ./build/X86/gem5.opt configs/learning_gem5/part1/simple.py
GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./build/X86/gem5.opt...done.
(gdb) b main
Breakpoint 1 at 0x4b0d20: main. (4 locations)
(gdb) run
Starting program: /home/hari/test-gem5-x86/build/X86/gem5.opt configs/learning_gem5/part1/simple.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Breakpoint 1, main (argc=2, argv=0x7fffffffdef8) at build/X86/sim/main.cc:42
42 {
(gdb) call schedBreak(10000)
warn: need to stop all queues
(gdb) c
Continuing.
gem5 Simulator System. http://gem5.org
gem5 is copyrighted software; use the --copyright option for details.
gem5 compiled Aug 26 2019 20:59:02
gem5 started Sep 8 2019 15:17:55
gem5 executing on nirmal-cadsl2, pid 30158
command line: /home/hari/test-gem5-x86/build/X86/gem5.opt configs/learning_gem5/part1/simple.py
Global frequency set at 1000000000000 ticks per second
warn: DRAM device capacity (8192 Mbytes) does not match the address range assigned (512 Mbytes)
0: system.remote_gdb: listening for remote gdb on port 7001
Beginning simulation!
info: Entering event queue # 0. Starting simulation...
Hello world!
Exiting # tick 501393000 because exiting with last active thread context
[Inferior 1 (process 30158) exited normally]
(gdb)
While this other tutorial http://gem5.org/wiki/images/0/0e/ASPLOS2017_gem5_tutorial.pdf (assuming the debug function is not particular to ISA) tells me that the function is actually schedBreakCycle(), it gives me this No symbol "schedBreakCycle" in current context. The full commands shown below.
➜ test-gem5-x86 git:(master) ✗ gdb --args ./build/X86/gem5.opt configs/learning_gem5/part1/simple.py
GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./build/X86/gem5.opt...done.
(gdb) b main
Breakpoint 1 at 0x4b0d20: main. (4 locations)
(gdb) run
Starting program: /home/hari/test-gem5-x86/build/X86/gem5.opt configs/learning_gem5/part1/simple.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Breakpoint 1, main (argc=2, argv=0x7fffffffdef8) at build/X86/sim/main.cc:42
42 {
(gdb) call schedBreakCycle(10000)
No symbol "schedBreakCycle" in current context.
(gdb)
gem5 version: ea8c435b6c6c092d72047eee50f125f5ae7347c3
gdb version: GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git
Also, if I want to debug ALPHA or ARM full system on my ubuntu 18.04(x86), do I have to use any cross-compiled gdb versions or would native gdb suffice?
The tutorial is correct, you have to pass --debug-break to gem5:
gdb --args gem5.debug --debug-break=1000 ...
and then without breaking at main:
run
call schedBreak(5000)
continue
--debug-break generates a break at time 1000 and makes GDB stop there after main, and from that point, schedBreak does work.
Or alternatively first go to:
tbreak doSimLoop
run
call schedBreak(5000)
continue
schedBreak schedules an event in the event queue, which cannot be ready at main.
The breaks work by raising a signal, which GDB stops at by default.
ALPHA and ARM won't make a difference since schedBreak is a tiny helper to debug the host emulator itself, which is likely an x86 program. To debug the guest code, which is what most people want, see e.g. this tutorial.
Tested gem5 master at e87a293d1ffa6da38ba8fa145e7dc5128138ab77 in an X86 debug build.
I'm trying to debug my program using C::B and added to the compiler settings:
#define
-DNDEBEUG
I get the log:
[debug]> run
[debug]No executable specified, use `target exec'.
[debug]Starting program:
[debug]>>>>>>cb_gdb:
Starting the debugger failed: No executable specified, use `target exec'.
[debug]> quit
Debugger finished with status 0
anyone can help please?
Breakpoints may not work if the folder you've placed your application has spaces or other special characters. replacing space with Underscore _ may solve the issue.
Click here for addition details to debug application in Code::blocks
After debugging for some hours, I am unable to debug my project I'm making anymore for the following reasons.
(It compiles smoothly without errors nor warnings from the compiler.)
Problem #1:
Error creating process d:\My
Documents\Downloads\CandyCrush\CandyCrush\bin\debug\CandyCrush.exe,
(error 5).
Solutions:
I followed the suggestions
here and here,
so I think it fixed one thing. ('spaces' in environment path)
Reboot the computer to ensure that the path is made available to all processes properly as suggested here. (Although its somewhat not really related to my problem)
Change the directory of my IDE along with the compiler.
Change the directory of the project I'm working on.
Delete and reinstall MinGW.
Delete and reinstall Code::Blocks.
And it changes the problem.
(take note that I always try to debug and run after each solutions)
Problem #2:
Starting debugger: D:\cb\CodeBlocks\MingGW\bin\gdb.exe -nx -fullname -quiet -args D:/CandyCrush/CandyCrush/bin/Debug/CandyCrush.exe failed
Solution:
Configure manually the path of debugger from the IDE (it says it can't find the file but it is there(?)) so it does fixed it.
Aaaand the first problem return again, so I think I really mess up things here.
What could be the fix?
PS. I'm using GNU gdb (GDB) 7.5
Edit
Full (Debug) log
Debugger name and version: GNU gdb (GDB) 7.5
[debug]>>>>>>cb_gdb: [debug]> set width 0 [debug]>>>>>>cb_gdb:
[debug]> set height 0 [debug]>>>>>>cb_gdb: [debug]> set breakpoint
pending on [debug]>>>>>>cb_gdb: [debug]> set print asm-demangle on
[debug]>>>>>>cb_gdb: [debug]> set unwindonsignal on
[debug]>>>>>>cb_gdb: [debug]> set print elements 0
[debug]>>>>>>cb_gdb: [debug]> set new-console on [debug]>>>>>>cb_gdb:
[debug]> set disassembly-flavor att [debug]>>>>>>cb_gdb: [debug]>
catch throw [debug]Catchpoint 1 (throw) [debug]>>>>>>cb_gdb: [debug]>
source D:\cb\CodeBlocks\share\codeblocks/scripts/stl-views-1.0.3.gdb
[debug]>>>>>>cb_gdb: [debug]> directory D:/CandyCrush/CandyCrush/
[debug]Source directories searched:
D:/CandyCrush/CandyCrush;$cdir;$cwd [debug]>>>>>>cb_gdb: [debug]> run
[debug]Error creating process
D:\CandyCrush\CandyCrush\bin\Debug\CandyCrush.exe, (error 5).
[debug]Starting program:
D:\CandyCrush\CandyCrush\bin\Debug\CandyCrush.exe
[debug]>>>>>>cb_gdb:
Error creating process
D:\CandyCrush\CandyCrush\bin\Debug\CandyCrush.exe, (error 5).
[debug]> quit
Debugger finished with status 0
This isn't good at all. After resting the IDE(compiler, debugger, editor) for some hours, it magically works again. I didn't close any application or reboot the computer.
Also It's because of Game Guard or Anti Virus
I'm trying to automate a gdb session using the --command flag. I'm trying to set a breakpoint on a function in a shared library (the Unix equivalent of a DLL) . My cmds.gdb looks like this:
set args /home/shlomi/conf/bugs/kde/font-break.txt
b IA__FcFontMatch
r
However, I'm getting the following:
shlomi:~/progs/bugs-external/kde/font-breaking$ gdb --command=cmds.gdb...
GNU gdb 6.8-2mdv2009.0 (Mandriva Linux release 2009.0)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i586-mandriva-linux-gnu"...
(no debugging symbols found)
Function "IA__FcFontMatch" not defined.
Make breakpoint pending on future shared library load? (y or [n]) [answered N; input not from terminal]
So it doesn't set the breakpoint after all. How can I make it default to answer "y" to set breakpoints on pending future shared library load?
I recall that I was able to do something, but cannot recall what.
Replying to myself, I'd like to give the answer that someone gave me on IRC:
(gdb) apropos pending
actions -- Specify the actions to be taken at a tracepoint
set breakpoint -- Breakpoint specific settings
set breakpoint pending -- Set debugger's behavior regarding pending breakpoints
show breakpoint -- Breakpoint specific settings
show breakpoint pending -- Show debugger's behavior regarding pending breakpoints
And so set breakpoint pending on does the trick; it is used in cmds.gdb like e.g.
set breakpoint pending on
break <source file name>:<line number>
OT: In terminal it would look like this to debug Caja in one line:
gdb -ex "set breakpoint pending on" -ex "break gdk_x_error" -ex run --args caja --sync
With no symbols.
objdump -t /lib/libacl.so
SYMBOL TABLE:
no symbols
objdump -T /lib/libacl.so
...
00002bd0 g DF .text 000000d0 ACL_1.0 acl_delete_entry
...
(gdb) break 0x0002bd0
(gdb) x/20i acl_delete_entry
0x2bd0 <acl_delete_entry>: stwu r1,-32(r1)
0x2bd4 <acl_delete_entry+4>: mflr r0
0x2bd8 <acl_delete_entry+8>: stw r29,20(r1)
0x2bdc <acl_delete_entry+12>: stw r30,24(r1)
0x2be0 <acl_delete_entry+16>: mr r29,r4
0x2be4 <acl_delete_entry+20>: li r4,28972