I am trying to debug my C code on CodeBlocks with GDB Debugger.
Unfortunately It does not work, I've tried almost everything including uninstall and re install CodeBlocks (debugger included).
Here's down below I'll put the exit error so you can get way better where the problem is:
Active debugger config: GDB/CDB debugger:Default
Building to ensure sources are up-to-date
Selecting target:
Release
Adding source dir: D:\20201105_es8_randomWalk\
Adding source dir: D:\20201105_es8_randomWalk\
Adding file: D:\20201105_es8_randomWalk\bin\Release\20201105_es8_randomWalk.exe
Changing directory to: D:/20201105_es8_randomWalk/.
Set variable: PATH=.;D:\programms\CodeBlocks\MinGW\bin;D:\programms\CodeBlocks\MinGW;C:\Windows\System32;C:\Windows;C:\Windows\System32\wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Windows\System32\OpenSSH;C:\Users\pnmat\AppData\Local\Microsoft\WindowsApps
Starting debugger: D:\programms\CodeBlocks\MinGW\bin\gdb.exe -nx -fullname -quiet -args D:/20201105_es8_randomWalk/bin/Release/20201105_es8_randomWalk.exe
done
Setting breakpoints
Reading symbols from D:/20201105_es8_randomWalk/bin/Release/20201105_es8_randomWalk.exe...(no debugging symbols found)...done.
Debugger name and version: GNU gdb (GDB) 8.1
No symbol table is loaded. Use the "file" command.
Temporary breakpoint 3 ("D:/20201105_es8_randomWalk/main.c:23") pending.
Child process PID: 8516 [Inferior 1 (process 8516) exited normally]
Debugger finished with status 0
It seems like it does not hit any breakpoint I've inserted in the code.
Related
Why does gdb not show the error context when I run gdb /bin/ls ?
I implemented my malloc using the malloc-tutorial (https://danluu.com/malloc-tutorial/), compiled it in a shared library and I want to replace the current malloc on system with my malloc using LD_PRELOAD to practice debugging.
But when I run it through gdb, I can't see the detailed error context like in the tutorial. Why?
My:
$ gdb /usr/bin/ls
Reading symbols from /usr/bin/ls...
Reading symbols from /usr/lib/debug/.build-id/2f/15ad836be3339dec0e2e6a3c637e08e48aacbd.debug...
(gdb) set environment LD_PRELOAD=/home/ays/work/malloc-tutorial/malloc.so
(gdb) run
Starting program: /usr/bin/ls
During startup program terminated with signal SIGSEGV, Segmentation fault.
(gdb) list
1435 src/ls.c: No such file or directory.
(gdb)
In tutorial:
$ gdb /bin/ls
(gdb) set environment LD_PRELOAD=./malloc.so
(gdb) run
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7bd7dbd in free (ptr=0x0) at malloc.c:113
113 assert(block_ptr->free == 0);
I noticed that when I run gdb /bin/ls, the symbols are read from usr/lib/debug/.... Is this ok?
gdb /bin/ls
Reading symbols from /bin/ls...
Reading symbols from /usr/lib/debug/.build-id/2f/15ad836be3339dec0e2e6a3c637e08e48aacbd.debug...
If I need source code besides debug symbols, how do I install it properly?
By the way, it is not mentioned here (https://wiki.ubuntu.com/DebuggingProgramCrash) that I need to install the source code for debug.
Here some info about my coreutils and coreutils-dbgsym:
$ sudo apt-get install coreutils-dbgsym
Reading package lists... Done
Building dependency tree
Reading state information... Done
coreutils-dbgsym is already the newest version (8.30-3ubuntu2).
0 upgraded, 0 newly installed, 0 to remove and 64 not upgraded.
$ apt-cache policy coreutils
coreutils:
Installed: 8.30-3ubuntu2
Candidate: 8.30-3ubuntu2
Version table:
*** 8.30-3ubuntu2 500
500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
100 /var/lib/dpkg/status
I installed Code::Blocks 17.12 on Windows 10 x64 using the defaults along with the built-in MinGW.
I created a new "Console Application" project for C. I attempted to run the program (debug) and it complained that gdb was not configured in the settings. I went to Settings > Debugger... the IDE settings and manually set the path to C:\CodeBlocks\MinGW\gdb32\bin\gdb32.exe which allowed me to compile and run.
The problem I'm having is that I've followed all of the defaults but the program does not pause after completion. I know that this can be worked around but this question is specifically regarding why this feature of Code::Blocks is failing.
There is a option for this in the IDE which is enabled by default in Project > Properties... > Build targets (tab) > Debug (target) > Pause when execution ends (checkbox) which is enabled by default:
Why is this feature failing?
I can confirm that the program does function by adding system("pause"); so it is not a runtime error.
The program is a basic "hello world" one:
#include <stdio.h>
#include <stdlib.h>
int main()
{
printf("Hello world!\n");
return 0;
}
Here is my build log:
Active debugger config: GDB/CDB debugger:Default
Building to ensure sources are up-to-date
Selecting target:
Debug
Adding source dir: C:\home\workspaces\learn-to-program-in-c\TestProject\Test\
Adding source dir: C:\home\workspaces\learn-to-program-in-c\TestProject\Test\
Adding file: C:\home\workspaces\learn-to-program-in-c\TestProject\Test\bin\Debug\Test.exe
Changing directory to: C:/home/workspaces/learn-to-program-in-c/TestProject/Test/.
Set variable: PATH=.;C:\CodeBlocks\MinGW\bin;C:\CodeBlocks\MinGW;C:\Windows\System32;C:\Windows;C:\Windows\System32\wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Program Files\Intel\WiFi\bin;C:\Program Files\Common Files\Intel\WirelessCommon;C:\Windows\System32\OpenSSH;C:\Users\Matthew D'Onofrio\AppData\Local\Microsoft\WindowsApps;C:\opt\Cygwin\x86\bin;C:\bin;C:\home\opt\Cygwin\x86\bin
Starting debugger: C:\CodeBlocks\MinGW\gdb32\bin\gdb32.exe -nx -fullname -quiet -args C:/home/workspaces/learn-to-program-in-c/TestProject/Test/bin/Debug/Test.exe
done
Setting breakpoints
Debugger name and version: GNU gdb (GDB) 7.9.1
Child process PID: 4092
[Inferior 1 (process 4092) exited normally]
Debugger finished with status 0
I'm trying to use OpenOCD with GDB to debug the STM32F4 Cortex-M4 on my STM32F4Discovery board.
Setup:
Ubuntu 16.04
OpenOCD 0.9.0 (also tested with 0.10-dev)
arm-none-eabi-gdb 7.10
STM32F4Discovery with ST-Link v2 (V2J28S0)
Project code generated with STM32CubeMX
I made sure debug wire is enabled in STM32CubeMX (this keeps the debug wire pins in default state)
GCC flags are:
-mcpu=cortex-m4 -mthumb -mthumb-interwork -mfloat-abi=hard -mfpu=fpv4-sp-d16 -ffunction-sections -fdata-sections -g -fno-common -fmessage-length=0
I added simple blinking LED code to the main loop, to test the debugging.
I start OpenOCD with openocd -f board/stm32f4discovery.cfg -c "program build/discovery_simple_test.elf verify reset". OpenOCD flashes the chip and resets it. (Output of OpenOCD can be found here)
Now I connect to it with GDB:
(gdb) target remote localhost:3333
Remote debugging using localhost:3333
0x08001450 in ?? ()
(gdb) set verbose on
(gdb) file "/abs_path/build/discovery_simple_test.elf"
A program is being debugged already.
Are you sure you want to change the file? (y or n) y
Load new symbol table from "/abs_path/build/discovery_simple_test.elf"? (y or n) y
Reading symbols from /abs_path/build/discovery_simple_test.elf...done.
Reading in symbols for /abs_path/Src/main.c...done.
(gdb) monitor reset
(gdb) break main
Breakpoint 1 at 0x8000232: file /abs_path/Src/main.c, line 71.
(gdb) break /abs_path/Src/main.c:93
Breakpoint 2 at 0x8000258: file /abs_path/Src/main.c, line 93.
The program should break at line 93, but it doesn't.
When I halt the execution and try to continue it, it doesn't continue:
(gdb) monitor halt
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x21000000 pc: 0x080006d8 msp: 0x2001ffe8
(gdb) monitor continue
//Program doesn't continue
What is going on and how can I fix it?
To fix this issue i add the following command in openocd :
-c gdb_breakpoint_override hard
May be another GDB-Instance is Running ?
"A program is being debugged already."
Look for a "arm-none-eabi-gdb" Process and kill it.
I guess the command to use is just continue and not monitor continue since you have to tell GDB that the underlying software is running.
monitor continue tells the embedded system to continue but GDB does not know about it (it does not interpret the meaning of the monitor command, openocd does).
I'm trying to use lldb with openocd/jtag board but I'm in trouble.
I already use openocd with gdb to develop on L0 STMicroelectronics board and it works perfectly.
Now I want the same with lldb.
I do that on LLDB host side
$ lldb bin/token.elf
(lldb) target create "bin/token.elf"
Current executable set to 'bin/token.elf' (arm).
(lldb) platform select remote-gdb-server
Platform: remote-gdb-server
Connected: no
(lldb) platform connect connect://localhost:5557
Platform: remote-gdb-server
Hostname: (null)
Connected: yes
(lldb) target list
Current targets:
* target #0: /home/cme/Projects/Tacos/ledger/trunk/se/build/st31_bolos/bin/token.elf ( arch=arm-unknown-unknown, platform=host )
On the openocd/GDB server side I correctly see the "Info : accepting 'gdb' connection on tcp/5557"
But now I don't found how to continue:
(lldb) process launch
error: process launch failed: Child exec failed.
I also tried "process continue", but lldb complains there is no process
With gdb, the process is considered as already running and I use reset/continue commands, never the 'run' command.
Does anybody know how to use lldb with openocd/jtag gdb-server?
Thanks for your help
C/M.
from what we were researching, it is not possible to debug remote (bare-metal!) targets with lldb without writing extra code.
for basic functionality, lldb needs to recognize at least one thread context.
the same is true for gdb. But there in gdb there is some sort of stub implemented faking an existing thread on the remote system. [1]
from an conversation on the lldb mailing list [2] the answer compiles to:
we have to write some (python) code to get a remote bare metal working with lldb.
[1] https://github.com/bminor/binutils-gdb/blob/28170b88cc8b40fdea2b065dafe6e1872a47ee4e/gdb/remote.c#L1808
[2] http://comments.gmane.org/gmane.comp.debugging.lldb.devel/3405
So far this works for me on my stm32g0b1 nucleo board and pyOCD but I also tested with OpenOCD
$ lldb --local-lldbinit Build/temp.elf
(lldb) target create "Build/temp.elf"
Current executable set to '/home/diego/Workspace/genesis/Buil /temp.elf' (arm).
(lldb) gdb-remote 127.0.0.1:3333
Process 1 stopped
(lldb) target modules load --load .text 0x08000000
section '.text' loaded at 0x8000000
(lldb) process plugin packet monitor reset halt
packet: qRcmd,72657365742068616c74
response: 526573657474696e672074617267657420776974682068616c740a5375636365737366756c6c792068616c74656420646576696365206f6e2072657365740a
I'm working on a patch for FFmpeg and need to debug my code. I'm loading an external library, and in order to test different library versions, I have them in different folders. To select which one I want to use, I've been using DYLD_LIBRARY_PATH=/path/to/lib/dir ./ffmpeg and that works okay. But when I try it within lldb, it crashes saying dyld: Library not loaded and Reason: image not found. This used to work pre-Xcode 7.1, but I just recently upgraded and it stopped working.
Here's my MVCE:
#include <stdio.h>
#include <stdlib.h>
int main() {
char* str = getenv("DYLD_LIBRARY_PATH");
if (str) puts(str);
else puts("(null)");
return 0;
}
Running this program as follows produces the output:
$ ./a.out
(null)
$ DYLD_LIBRARY_PATH=/tmp ./a.out
/tmp
That looks okay. But when I try to use lldb it fails:
$ DYLD_LIBRARY_PATH=/tmp lldb ./a.out
(lldb) target create "./a.out"
Current executable set to './a.out' (x86_64).
(lldb) run
Process 54255 launched: './a.out' (x86_64)
(null)
Process 54255 exited with status = 0 (0x00000000)
Trying to set the environment variable inside lldb works:
lldb ./a.out
(lldb) target create "./a.out"
Current executable set to './a.out' (x86_64).
(lldb) env DYLD_LIBRARY_PATH=/tmp
(lldb) run
Process 54331 launched: './a.out' (x86_64)
/tmp
Process 54331 exited with status = 0 (0x00000000)
lldb version (it's from Xcode 7.1):
$ lldb --version
lldb-340.4.110
Question: Is this an intended new "feature," or is this a new bug in lldb (or am I totally crazy and this never used to work)? I'm quite positive lldb used to forward the DYLD_LIBRARY_PATH environment variable, so how come it isn't anymore?
Edit: This is on OS X 10.11.1.
If this is on El Capitan (OS X 10.11), then it's almost certainly a side effect of System Integrity Protection. From the System Integrity Protection Guide: Runtime Protections article:
When a process is started, the kernel checks to see whether the main
executable is protected on disk or is signed with an special system
entitlement. If either is true, then a flag is set to denote that it
is protected against modification. …
… Any dynamic linker (dyld)
environment variables, such as DYLD_LIBRARY_PATH, are purged when
launching protected processes.
Everything in /usr/bin is protected in this fashion. Therefore, when you invoke /usr/bin/lldb, all DYLD_* environment variables are purged.
It should work to run lldb from within Xcode.app or the Command Line Tools, like so:
DYLD_LIBRARY_PATH=whatever /Applications/Xcode.app/Contents/Developer/usr/bin/lldb <whatever else>
I don't believe that copy of lldb is protected. /usr/bin/lldb is actually just a trampoline that executes the version in Xcode or the Command Line Tools, so you're ultimately running the same thing. But /usr/bin/lldb is protected so the DYLD_* environment variables are purged when running that.
Otherwise, you will have to set the environment variable inside lldb as shown in this thread:
(lldb) process launch --environment DYLD_LIBRARY_PATH=<mydylibpath> -- arg1 arg2 arg3
or using the short -v option:
(lldb) process launch -v DYLD_LIBRARY_PATH=<mydylibpath> -- arg1 arg2 arg3
Or, you can disable System Integrity Protection, although it serves a good purpose.
You can set an environment variable inside lldb once it is started.
$ lldb
(lldb) help env
Shorthand for viewing and setting environment variables. Expects 'raw' input (see 'help raw-input'.)
Syntax:
_regexp-env // Show environment
_regexp-env <name>=<value> // Set an environment variable
'env' is an abbreviation for '_regexp-env'
(lldb)
So that
lldb ./a.out
(lldb) env DYLD_LIBRARY_PATH=/path/to/lib/dir
(lldb) r
should work.
Tested with
$ lldb --version
lldb-1400.0.38.17
Apple Swift version 5.7.2 (swiftlang-5.7.2.135.5 clang-1400.0.29.51)