How to debug Fiware-Orion - c++

I'm new to this field.
I've installed Fiware-orion via source on my VM (centOS), by following the link below:
https://fiware-orion.readthedocs.io/en/master/admin/build_source/index.html.
Currently I'm working on a Fiware-Orion issue, but I don't know how to debug Fiware-Orion. I've searched on google and Official documentation of Fiware-Orion but I don't find any relative documentation/material related to Fiware-Orion debugging.
I've find some commands related to Orion debugging (but I don't know whether these commands are correct or not) and I'm following these commands:
-> First installed orion from source and mongoDB then,
make di
./BUILD_DEBUG/src/app/contextBroker/contextBroker -port 1026
curl localhost:1026/version
gdb ./BUILD_DEBUG/src/app/contextBroker/contextBroker -tui
b (lineNo)
run
[root#localhost fiware-orion]# gdb ./BUILD_DEBUG/src/app/contextBroker/contextBroker
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-100.el7
Copyright (C) 2013 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-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /root/workingDir/fiware-orion/BUILD_DEBUG/src/app/contextBroker/contextBroker...done.
(gdb) b 101
Breakpoint 1 at 0x6033c9: file /root/workingDir/fiware-orion/src/app/contextBroker/contextBroker.cpp, line 101.
(gdb) run
Starting program: /root/workingDir/fiware-orion/./BUILD_DEBUG/src/app/contextBroker/contextBroker
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Breakpoint 1, fileExists (path=0xbfc380 <pidPath> "/tmp/contextBroker.pid")
at /root/workingDir/fiware-orion/src/app/contextBroker/contextBroker.cpp:371
371 if (access(path, F_OK) == 0)
Missing separate debuginfos, use: debuginfo-install boost-filesystem-1.53.0-27.el7.x86_64 boost-regex-1.53.0-27.el7.x86_64 boost-system-1.53.0-27.el7.x86_64 boost-thread-1.53.0-27.el7.x86_64 cyrus-sasl-lib-2.1.26-23.el7.x86_64 glibc-2.17-292.el7.x86_64 gmp-6.0.0-15.el7.x86_64 gnutls-3.3.29-9.el7_6.x86_64 keyutils-libs-1.5.8-3.el7.x86_64 krb5-libs-1.15.1-37.el7_7.2.x86_64 libcom_err-1.42.9-16.el7.x86_64 libcurl-7.29.0-54.el7_7.1.x86_64 libffi-3.0.13-18.el7.x86_64 libgcc-4.8.5-39.el7.x86_64 libgcrypt-1.5.3-14.el7.x86_64 libgpg-error-1.12-3.el7.x86_64 libicu-50.1.2-15.el7.x86_64 libidn-1.28-4.el7.x86_64 libselinux-2.5-14.1.el7.x86_64 libssh2-1.8.0-3.el7.x86_64 libstdc++-4.8.5-39.el7.x86_64 libtasn1-4.10-1.el7.x86_64 libuuid-2.23.2-61.el7_7.1.x86_64 nettle-2.7.1-8.el7.x86_64 nspr-4.21.0-1.el7.x86_64 nss-3.44.0-7.el7_7.x86_64 nss-softokn-freebl-3.44.0-8.el7_7.x86_64 nss-util-3.44.0-4.el7_7.x86_64 openldap-2.4.44-5.el7.x86_64 openssl-libs-1.0.2k-19.el7.x86_64 p11-kit-0.23.5-3.el7.x86_64 pcre-8.32-17.el7.x86_64 zlib-1.2.7-18.el7.x86_64
(gdb) list
366 *
367 * fileExists -
368 */
369 static bool fileExists(char* path)
370 {
371 if (access(path, F_OK) == 0)
372 {
373 return true;
374 }
375
(gdb) n
376 return false;
(gdb) n
377 }
(gdb) n
pidFile (justCheck=true) at /root/workingDir/fiware-orion/src/app/contextBroker/contextBroker.cpp:397
397 if (justCheck == true)
(gdb) print justCheck
$1 = true
(gdb) list
876 {
877 LM_X(1, ("Fatal Error (when option '-https' is used, option '-cert' is mandatory)"));
878 }
879 }
880
881 notificationModeParse(notificationMode, &notificationQueueSize, &notificationThreadNum); // This should be called before contextBrokerInit()
882 LM_T(LmtNotifier, ("notification mode: '%s', queue size: %d, num threads %d", notificationMode, notificationQueueSize, notificationThreadNum));
883 LM_I(("Orion Context Broker is running"));
884
885 if (fg == false)
(gdb) n
882 LM_T(LmtNotifier, ("notification mode: '%s', queue size: %d, num threads %d", notificationMode, notificationQueueSize, notificationThreadNum));
(gdb) step
883 LM_I(("Orion Context Broker is running"));
(gdb)
While I'm using skip(i.e. 's') command to enter into the function but it moves to the next line. I don't know where I'm making mistakes.
Actually I wanted to debug the files present inside https://github.com/telefonicaid/fiware-orion/blob/master/src/lib/ folders but I'm not able to reach there. Even, I'm not able to move out of fiware-orion/src/app/contextBroker/contextBroker.cpp class.
Can anyone suggest me correct commands for debugging Fiware-Orion, or tell me where I'm making mistakes, please.
Is there any proper documentation available regarding to debugging the Fiware-Orion?

To debug Orion you would need it compiled in DEBUG mode. The release that you have installed is not. To get a debuggable Orion, you'll have to build it from source, and compile it for debugging.
To build Orion from sources, check out the documentation here: https://github.com/telefonicaid/fiware-orion/blob/master/doc/manuals/admin/build_source.md.
Build Orion using the make target "di", which stands for "debug install".
Good luck!

If you simply want to increase the debug level of Orion itself, the command line arguments are simply:
orion -logLevel DEBUG -t 0-255 -noCache -logForHumans
For example, when using a Dockerized Orion, the following docker-compose could be used:
orion:
image: fiware/orion:${ORION_VERSION}
hostname: orion
container_name: fiware-orion
depends_on:
- mongo-db
networks:
- default
expose:
- "${ORION_PORT}"
ports:
- "${ORION_PORT}:${ORION_PORT}" # localhost:1026
command: -dbhost mongo-db -logLevel DEBUG -noCache -logForHumans
healthcheck:
test: curl --fail -s http://orion:${ORION_PORT}/version || exit 1

In my case, I use QtCreator as IDE (in particular, version 3.5.1, a bit old but it works :). QtCreator integrates nicely with gdb, so it is easy to run Orion in debug mode, set breakpoints in the graphical code editor, then stimulate Orion with requests and see how it goes (breakpoint reached, etc.).

Related

schedBreak(<tick>) gdb debugging function not working

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.

remote core file analysis with eclipse

I want to use eclipse IDE as front-end GUI to debug a core file of another OS that is docker'ed in my host. With 'gdbserver' in the docker i can only debug a running process. But i need post-mortem debugging of core files.
I tried some /home/me/bin/remote_gdb wrapper that uses
docker exec -it $DOCKER_CONTAINER bash -c "gdb /usr/bin/executable /opt/crash/executable.core
This works using in a shell. But it fails using in 'eclipse' because of
Could not determine GDB version using command: remote_gdb --version
even though 'remote_gdb --version' prints out exactly the same as the original 'gdb --version'.
I could make something work with 'ddd' as a front-end - let me exercise:
> cd $HOME/SRC
> ls -l
total 4
-rw-rw-r-- 1 frank frank 96 Aug 24 18:04 test.c
> cat test.c
#include <stdio.h>
int main(int argc, char** argv)
{
printf("hello, world!\n");
return 0;
}
> docker run -v $HOME/SRC:/SRC -t fedora /bin/bash
// IN DOCKER NOW:
>> yum install gcc
[...]
>> yum install gdb
[...]
>> cd /SRC
>> gcc -g3 -O0 -o test test.c
>> ls -l
total 40
-rwxr-xr-x 1 root root 34864 Aug 24 16:26 test
-rw-rw-r-- 1 1000 1000 96 Aug 24 16:04 test.c
Back in Host:
> docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
e501d8384060 fedora "/bin/bash" 4 minutes ago Up 4 minutes stupefied_murdock
> cat $HOME/bin/remote_gdb
#!/bin/bash
docker exec -it e501d8384060 gdb /SRC/test
> remote_gdb # $HOME/bin/ is in $PATH
GNU gdb (GDB) Fedora 8.0-20.fc26
Copyright (C) 2017 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-redhat-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 /SRC/test...done.
(gdb) list
1 #include <stdio.h>
2
3 int main(int argc, char** argv)
4 {
5 printf("hello, world!\n");
6 return 0;
7 }
8
(gdb)
Switching back to the shell, where i am in the docker - see 'gdb' is running:
>> yum install procps-ng
[...]
>> ps -ef
UID PID PPID C STIME TTY TIME CMD
root 1 0 0 16:22 ? 00:00:00 /bin/bash
root 16 0 0 16:23 ? 00:00:00 bash
root 116 0 0 16:28 ? 00:00:00 gdb /SRC/test
root 131 16 0 16:30 ? 00:00:00 ps -ef
Back again on the host shell (after quit gdb session in docker):
> ddd --debugger remote_gdb
The 'ddd' plays nicely with gdb started in docker.
And it also works with core-files (add a "sleep(100);" and kill the process).
But 'ddd' doesn't have a really good GUI.
So what's the way to make such work with 'eclipse'?
I also couldn't make it work with other options: 'qtcreator', 'kdevelop', 'nemiver', 'kdbg', etc
Addendum:
It also doesn't work with 'ssh' into container.
But when i execute the same 'remote_gdb' wrapper script as 'External Tool' it can be executed(?!)
I partially could solve the issue.
The main problem was: my docker command does not provide a tty to eclipse.
As a workaround i switched over to 'ssh' into the docker image.
Moreover i had to align the file locations (executable, core-file and source-files) between host and docker image. Because using a 'gdb' wrapper script, 'eclipse' is not aware that i am debugging remotely and verifies all files for local availability.
This works for post-mortem debugging (core file analysis) and attaching a running process in docker (in general on the remote system).
However, it does not work for starting up a process in gdb via eclipse.
So used 'strace' to check for the activities between 'eclipse' and 'gdb' and found out, that for starting up a new process in 'gdb', 'eclipse' tries to apply some '--interpreter mi2 -nx' command:
inferior-tty-set --thread-group i1 /dev/pts/27
Does it mean it tries to bind a local tty to gdb?
That of course does not work remotely.
What is the reason to use "inferior-tty-set" by 'eclipse'?
It doesn't use this command for doing post-mortem debugging or attaching a running process - while for both i even have a gdb console operable in 'eclipse'
?

Reading peripheral register of Cortex M0 MCU using JLink and GDB

I'm trying to read the MCUs ADC register using GDB but I can't seem to find how it's done.
Using x\10x 0x40012708 in gdb just returns zeroes, as do any memory mapped peripheral register I try to read.
It this possible to do? If so, how is it done?
Thanks!
I would suggest to validate that your setup is functional first.
For example, you could try to read the CPUID register which is present on all Cortex-M0 processors - see section 4.3 of the Cortex™-M0 DevicesGeneric User Guide.
It is located at address 0xE000ED00, and it shall contain value 0x410CC200.
If you can read it, this would be a good sign.
You probably should try using J-Link commander first, then with GDB-Server and GDB. I ran the procedure hereafter on an Olimex board using an LPC1114/301 Cortex-M0. I was using J-Link software V5.10n, and arm-none-eabi-gdb version 7.10.1.20151217-cvs, which is part of Linaro gcc 5.2 for ARM Cortex-M processors package.
Start JLink.exe using the following options:
jlink.exe -if SWD -speed 4000 -AutoConnect 1 -device Cortex-M0
You should see something similar to:
SEGGER J-Link Commander V5.10n (Compiled Feb 19 2016 18:39:46)
DLL version V5.10n, compiled Feb 19 2016 18:39:11<br/>
Connecting to J-Link via USB...O.K.
Firmware: J-Link ARM V8 compiled Nov 28 2014 13:44:46
Hardware version: V8.00
S/N: [My J-Link EDU Serial Number]
License(s): FlashBP, GDB
OEM: SEGGER-EDU
Emulator has Trace capability
VTref = 3.313V
Device "CORTEX-M0" selected.
Found SWD-DP with ID 0x0BB11477
Found Cortex-M0 r0p0, Little endian.
FPUnit: 4 code (BP) slots and 0 literal slots
CoreSight components:
ROMTbl 0 # E00FF000
ROMTbl 0 [0]: FFF0F000, CID: B105E00D, PID: 000BB008 SCS
ROMTbl 0 [1]: FFF02000, CID: B105E00D, PID: 000BB00A DWT
ROMTbl 0 [2]: FFF03000, CID: B105E00D, PID: 000BB00B FPB
Cortex-M0 identified.
J-Link>
You can now read the CPUID register using the J-Link commander mem32 command, and verify the CPUID register does contain the expected value:
J-Link>mem32 0xE000ED00,1
You should get:
E000ED00 = 410CC200
If this is the case, I would say that your J-Link/Cortex-M0 setup is likely functional. We can now verify GDB Server and GDB are working fine too.
Launch JLinkGDBServerCL.exe with the following options: JLinkGDBServerCL.exe -if SWD -speed 4000 -device Cortex-M0
SEGGER J-Link GDB Server V5.10n Command Line Version
JLinkARM.dll V5.10n (DLL compiled Feb 19 2016 18:39:11)
-----GDB Server start settings-----
GDBInit file: none
GDB Server Listening port: 2331
SWO raw output listening port: 2332
Terminal I/O port: 2333
Accept remote connection: localhost only
Generate logfile: off
Verify download: off
Init regs on start: off
Silent mode: off
Single run mode: off
Target connection timeout: 0 ms
------J-Link related settings------
J-Link Host interface: USB
J-Link script: none
J-Link settings file: none
------Target related settings------
Target device: Cortex-M0
Target interface: SWD
Target interface speed: 4000kHz
Target endian: little
Connecting to J-Link...
J-Link is connected.
Firmware: J-Link ARM V8 compiled Nov 28 2014 13:44:46
Hardware: V8.00
S/N: [My J-Link EDU Serial Number]
OEM: SEGGER-EDU
Feature(s): FlashBP, GDB
Checking target voltage...
Target voltage: 3.31 V
Listening on TCP/IP port 2331
Connecting to target...Connected to target
Waiting for GDB connection...
Keep the GDB server running, and start GDB in an other Windows console session:
arm-none-eabi-gdb
GNU gdb (GNU Tools for ARM Embedded Processors) 7.10.1.20151217-cvs
Copyright (C) 2015 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 "--host=i686-w64-mingw32 --target=arm-none-eabi".
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".
We can now connect to GDB server, and attempt to display the content of the CPUID register again:
(gdb) target remote localhost:2331
Remote debugging using localhost:2331
0xfffffffe in ?? ()
(gdb) monitor halt
(gdb) monitor reset
Resetting target
(gdb) x/1xw 0xE000ED00
0xe000ed00: 0x410cc200
(gdb)
If you are getting 0x410cc200 again, your J-Link/Cortex-m0/GDB Server/GDB setup should be functional, and you should now try again to read your ADC register using this command:
x/1xw 0x40012708
If you were able to read the CPUID register, but not the ADC register, and if the address for the ADC register is correct, I would not have an explanation for this behavior right now - knowing the exact brand/model for the MCU you are using could of course help further.
Please note that from now on, you should specify the exact model for your MCU as the argument to the -device J-Link Commander/GDB Server options instead of Cortex-M0. You can get the list by entering command ? on the J-Link Commander command-prompt.

Debug Q With GDB Debugger

This is really a general question.
And I've tried looking around for help but it's about the gdp debugger.
I compile a program, it takes two strings as arguments.
I run it with r and the two parameters following it, but when I insert a break like ' break 33 ' and break at line 33 and then run it again, I cannot step into it and it doesn't stop at my break.
I can't step break continue etc.
gcc -g -o debugme debugme.c
Directory: /home/
Tue Oct 6 20:03:14 EDT 2015
[]$ debugme "hi there" "bye bye"
String '0' - 'debugme'
String '1' - 'hi there'
String '2' - 'bye bye'
Total number of command-line arguments: 2
(gdb)
Tue Oct 6 20:06:56 EDT 2015
[]$ cd cosc220
[]$ gdb debugme
GNU gdb (GDB; openSUSE 13.1) 7.6.50.20130731-cvs
Copyright (C) 2013 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-suse-linux".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://bugs.opensuse.org/>.
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 /home/...done.
(gdb) break 33
Breakpoint 1 at 0x4005c7: file debugme.c, line 33.
(gdb) delete 1
(gdb)
(gdb) break 33
Breakpoint 2 at 0x4005c7: file debugme.c, line 33.
(gdb)
What do I need to type for this to work?
It tells me my program isn't running, I try viewing my call stack and it's empty
I type r for run later (I just didn't include it here)
You need to hit r at the gdb so that your program again start running.
What do I need to type for this to work?
You should probably read an introduction, such as this one.
The command you are looking for is run, but once you run your program to the breakpoint, it's likely that you'll have more questions, so starting at introduction may still be a good idea.
It turns out that we didn't have it installed on the server at my school...
Face-palm, it's working now.

gdb fails on mountain lion

I tried to compile a 7.x Version of gdb without any luck.
I codesigned the executable(http://sourceware.org/gdb/wiki/BuildingOnDarwin).
With following version there were these problems.
7.5,7.4,git clone: unknown load command 0x2a (and others) for my application and different system libraries when starting gbd. When trying to print a vector for example i always get:
Could not find the frame base for "main(int, char**)"
7.3 (macports and from gdb-website): on starting the application it fails to set the breakpoint and continues to run.
(gdb) start
Temporary breakpoint 1 at 0x100000950: file ../src/main.cpp, line 15.
Starting program: [...]
BFD: unable to read unknown load command 0x24
BFD: unable to read unknown load command 0x2a
BFD: unable to read unknown load command 0x26
Error in re-setting breakpoint 1: Cannot access memory at address 0x100000950
[application continues]
I used the system llvm-gcc, gcc4.7 and svn-gcc4.8 to compile.
Has anybody succeeded in installing gdb on Mountain Lion?
i installed gdb 7.5 on mountain lion without problems...
those steps might help you: ./configure --prefix=/usr/local
--enable-targets=x86_64-apple-darwin10 --enable-64-bit-bfd --disable-werror --build=x86_64-apple-darwin10 --host=x86_64-apple-darwin10 --target=x86_64-apple-darwin10
then make install gdb.
create your own certificate like discribed here and sign the gdb
http://sourceware.org/gdb/wiki/BuildingOnDarwin
you have to explicitly state: codesign -s gdb-cert /usr/local/gdb
before you sign the gdb make sure you already set your certificate
to trusted. also close the keychain before signing your gdb.
hope this also works for your
I resolved this issue by following the steps tried here: http://coding.derkeiler.com/Archive/Ada/comp.lang.ada/2012-09/msg00305.html
Steps
sudo chgrp procmod /usr/local/bin/gdb
sudo chmod g+s /usr/local/bin/gdb
Edit /System/Library/LaunchDaemons/com.apple.taskgated.plist and add +p argument to taskgated process
Force kill taskgated process (it will restart)
Try again
Other links:
https://blogs.oracle.com/dns/entry/understanding_the_authorization_framework_on
it doesn't seem to work for me... same issue as with the default homebrew settings
v1:src zeph$ brew install gdb
==> Downloading http://ftpmirror.gnu.org/gdb/gdb-7.5.tar.bz2
Already downloaded: /Library/Caches/Homebrew/gdb-7.5.tar.bz2
==> ./configure --prefix=/usr/local/Cellar/gdb/7.5 --with-python=/usr --with-system-readline --enable-targets=x86_64-apple-darwin10 --enable-64-bit-bfd --disable-werror --build=x86_64-apple-darwin10 --hos
==> make
==> make install
==> Caveats
gdb requires special privileges to access Mach ports.
You will need to codesign the binary. For instructions, see:
http://sourceware.org/gdb/wiki/BuildingOnDarwin
==> Summary
/usr/local/Cellar/gdb/7.5: 62 files, 9.3M, built in 119 seconds
v1:src zeph$ codesign -s gdb-cert /usr/local/Cellar/gdb/7.5/bin/gdb
v1:src zeph$ /usr/local/Cellar/gdb/7.5/bin/gdb --args /Users/zeph/tmp/CouchBase/src/install/bin/memcached -d -u root -P /tmp/0libmemcached_memc.pid -t 1 -p 11221 -U 11221 -m 128
GNU gdb (GDB) 7.5
Copyright (C) 2012 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-apple-darwin10".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
BFD: /Users/zeph/tmp/CouchBase/src/install/bin/memcached: unknown load command 0x29
BFD: /Users/zeph/tmp/CouchBase/src/install/bin/memcached: unknown load command 0x29
Reading symbols from /Users/zeph/tmp/CouchBase/src/install/bin/memcached...done.
(gdb) run
Starting program: /Users/zeph/tmp/CouchBase/src/install/bin/memcached -d -u root -P /tmp/0libmemcached_memc.pid -t 1 -p 11221 -U 11221 -m 128
Unable to find Mach task port for process-id 28755: (os/kern) failure (0x5).
(please check gdb is codesigned - see taskgated(8))
(gdb)
k, I had to re-sign it after having TRUSTED the certificate all across the board
codesign -fs gdb-cert /usr/local/Cellar/gdb/7.5/bin/gdb
There were two issues in the OP's question. The one regarding signing the executable or modifying taskgated and using setgid procmod has been covered. The second issue is the warnings about unknown load commands. I too ran into this and after a bunch of searching came across the following patches, that fix it:
https://gist.github.com/davidbalbert/4197567