Installing G++ on a Mac

1. Gdb Macro Expand
2. Gdb For Macos
3. Gdb Machine Code
4. Install Gdb For Mac
5. Mac Gdb Codesign

This section is intended to get you quickly started with C++ programming on your Mac. We'll be installing GCC 4.8.1 and GDB through a tool called Homebrew. If you want an additional guide on all of the following steps (except for installing GCC), the one by Moncef Belyamani is quite helpful. When you follow it, ignore anything about installing Ruby; that is, stop after setting up git.

Homebrew

Homebrew 'installs the stuff that you need that Apple don't'. It's like Ubuntu's apt-get, where one can install packages easily from repositories. Instead of having to download, configure, and install something yourself, all you need to do is run one command, and Homebrew will take care of the rest for you.

Information about Steps to install GDB in Mac: If you want to install a GDB in Mac then firstly you have to download a GDB from MinGW and install it at the same location (c:/MinGW by default). After that you have to install a eclipse and MinGW. I got gdb working on Mojave by: a) getting the latest gdb source archive (at time of writing, ftp://sourceware.org/pub/gdb/snapshots/current/gdb-weekly-8.2.50. GDB 8.1 is broken on macOS 10.13. Bug 1, Bug 2. You need to downgrade to 8.0 for the time being, see this answer on how to do that. I had to run 10. Above with sudo.

1. I'm trying to open a GDB on QGIS for Mac but having no luck. Details: I'm currently running OS 10.9.3 on my laptop. I downloaded and installed QGIS 2.6.1-2 from KyngChaos I installed the GDAL com.
2. The officially supported debugging package for Mac OS X is lldb, which is a fine debugger. However, many people including me still prefer to use gdb, the GNU debugger. In fact, I use cgdb, which provides nice color interface to gdb, and that is why I must install gdb on my Mac.
3. How to Use GDB as a Poor Man’s Profiler November 2, 2010 by kristian By following exactly the steps you can often spot if application is in an infinite loop, or if it’s just making really slow progress or swapping memory like crazy.
4. GDB Installation on Mac OS X. If you work on a Mac OS X 10.9 Mavericks or later, you will run into the problem of Eclipse refusing to interactively debug problems that otherwise build and run fine: An attempt to start a debugging session by selecting Run Debug.

Pre-requisites

Homebrew requires that you have either Xcode or the Xcode command line tools installed on your Mac. Xcode is a free integrated development environment similar to Eclipse designed by Apple and mainly intended for iOS development or targeting the clang compiler. In this class, we will focus on gcc.

Xcode is quite a big install, so if you do not want to install it, you can get away with just installing the Xcode command line tools. See a Stackoverflow discussion for instructions on how to install the command line tools regardless of whether you have Xcode installed.

Installing Homebrew

You need xcode command line tools to install Homebrew. It is very easy to install Homebrew. Open your terminal, and run the following command:

If this doesn't seem to do anything, try killing it (CTRL C) and running it again. Or checkout homebrew website.

GCC and GDB

Installing GCC

As mentioned before, installing packages with Homebrew is very easy. First, we will add the repository from which the GCC package is available, so that Homebrew knows where to find the package we want. The repository is at https://github.com/Homebrew/homebrew-versions.

We do this by using the brew-tap command. Keep your terminal open, and run the following command. (For more information on how brew-tap works, visit the Homebrew docs):

Next, we will actually install the GCC package. Run the following command:

It might take a while before the installation is complete. When done, run the following:

The result should look like this:

USC Wireless Warning

Many people have had issues running the brew install commands while connected to USC Wireless. If you are having trouble, you can either try using a wired connection, a different wireless connection, or do the following:

1. Download a homebrew cache
2. Open Finder, press CMD (command) + SHIFT + G and type /Library/Caches/Homebrew

3. Extract the contents of the .zip you downloaded inside of the folder you opened in the previous step. Do not extract any of the .tar.bz2 or .tar.gz inside of the .zip folder.This should look as follows:

4. Run brew install gcc48 in the Terminal as instructed above.

Using G++

To compile with the newly installed G++ compiler, use g++-4.8.

(Advanced) Aliasing g++

If you prefer calling g++ directly, you can also create a bash alias, as follows:

Put these two lines at the end of the file ~/.bashrc, and run:source ~/.bashrc

For more information on bash alias, take a look at the GNU Docs.

Installing GDB

Here also we use Homebrew. The following instruction has been taken from GDB on OS X Mavericks and Xcode 5 guide. To install, run the following brew command.

Check if it's installed:

The result should be gdb version 7 or higher.

Codesigning gdb

gdb is not going to debug yet. You'll get an error message like 'please check gdb is codesigned'. You need to create a certificate and sign gdb. By doing so you're telling the operating system that gdb is authorized to attach to other processes for debugging purposes. The following instructions have been taken from this Code Signing guide.

1. Open application 'Keychain Access' (/Applications/Utilities/Keychain Access.app)

2. In Keychain Access, select the 'login' keychain in the 'Keychains' list in the upper left hand corner of the window.

3. Open the menu item in /Keychain Access/Certificate Assistant/Create a Certificate...

4. Choose a name ('lldb_codesign' in the example, but you can use anything you want), set 'Identity Type' to 'Self Signed Root', and set 'Certificate Type' to 'Code Signing'. Click 'Create'.

5. Click continue, continue and done.

6. Click on the “My Certificates” category on the left side and double click on the new “lldb_codesign” certificate.

7. Open the context menu for 'Trust' (click the triangle) and change the following:When using this certificate: Always Trust

8. Now close this window, and enter your login password to confirm this change.

9. Option-drag (this meaning holding the option key down and dragging) the new 'lldb_codesign' certificate from the login keychain to the System keychain in the Keychains pane of the main Keychain Access window to make a copy of this certificate in the System keychain. You'll have to authorize a few more times, set it to be 'Always trusted' when asked.

10. Switch to the 'System' keychain and drag a copy of the 'lldb_codesign' you just made onto the Desktop.

11. Switch to Terminal and then run the following command (copy paste it!): sudo security add-trust -d -r trustRoot -p basic -p codeSign -k /Library/Keychains/System.keychain ~/Desktop/lldb_codesign.cer

12. Then right click on the 'lldb_codesign' certificate in the 'System' keychain (not 'Login') and select 'delete' to delete it from the 'System' keychain.

13. Then reboot your system/computer.

14. Finally you can sign gdb:codesign -s lldb_codesign /usr/local/bin/gdb

15. If this command doesn't work...then panic! Just kidding, be sure that you have gdb installed and that gdb is actually installed in /usr/local/bin. You may want to try 'which gdb' in your Terminal to figure out where it is.

16. Finally, remove the lldb_codesign.cer file that's sitting on your desktop, and gdb should be working at this point. :)

Next: Forks, Previous: Inferiors and Programs, Up: Running [Contents][Index]

4.10 Debugging Programs with Multiple Threads

Gdb Macro Expand

In some operating systems, such as GNU/Linux and Solaris, a single programmay have more than one thread of execution. The precise semanticsof threads differ from one operating system to another, but in generalthe threads of a single program are akin to multiple processes—exceptthat they share one address space (that is, they can all examine andmodify the same variables). On the other hand, each thread has its ownregisters and execution stack, and perhaps private memory.

GDB provides these facilities for debugging multi-threadprograms:

• automatic notification of new threads
• ‘thread thread-id’, a command to switch among threads
• ‘info threads’, a command to inquire about existing threads
• ‘thread apply [thread-id-list | all] args’,a command to apply a command to a list of threads
• thread-specific breakpoints
• ‘set print thread-events’, which controls printing of messages on thread start and exit.
• ‘set libthread-db-search-path path’, which letsthe user specify which libthread_db to use if the default choiceisn’t compatible with the program.

The GDB thread debugging facility allows you to observe allthreads while your program runs—but whenever GDB takescontrol, one thread in particular is always the focus of debugging.This thread is called the current thread. Debugging commands showprogram information from the perspective of the current thread.

Whenever GDB detects a new thread in your program, it displaysthe target system’s identification for the thread with a message in theform ‘[New systag]’, where systag is a thread identifierwhose form varies depending on the particular system. For example, onGNU/Linux, you might see

when GDB notices a new thread. In contrast, on other systems,the systag is simply something like ‘process 368’, with nofurther qualifier.

For debugging purposes, GDB associates its own thread number—always a single integer—with each thread of an inferior. Thisnumber is unique between all threads of an inferior, but not uniquebetween threads of different inferiors.

You can refer to a given thread in an inferior using the qualifiedinferior-num.thread-num syntax, also known asqualified thread ID, with inferior-num being the inferiornumber and thread-num being the thread number of the giveninferior. For example, thread 2.3 refers to thread number 3 ofinferior 2. If you omit inferior-num (e.g., thread 3),then GDB infers you’re referring to a thread of the currentinferior.

Until you create a second inferior, GDB does not show theinferior-num part of thread IDs, even though you can always usethe full inferior-num.thread-num form to refer to threadsof inferior 1, the initial inferior.

Some commands accept a space-separated thread ID list asargument. A list element can be:

1. A thread ID as shown in the first field of the ‘info threads’display, with or without an inferior qualifier. E.g., ‘2.1’ or‘1’.
2. A range of thread numbers, again with or without an inferiorqualifier, as in inf.thr1-thr2 orthr1-thr2. E.g., ‘1.2-4’ or ‘2-4’.
3. All threads of an inferior, specified with a star wildcard, with orwithout an inferior qualifier, as in inf.* (e.g.,‘1.*’) or *. The former refers to all threads of thegiven inferior, and the latter form without an inferior qualifierrefers to all threads of the current inferior.

For example, if the current inferior is 1, and inferior 7 has onethread with ID 7.1, the thread list ‘1 2-3 4.5 6.7-9 7.*’includes threads 1 to 3 of inferior 1, thread 5 of inferior 4, threads7 to 9 of inferior 6 and all threads of inferior 7. That is, inexpanded qualified form, the same as ‘1.1 1.2 1.3 4.5 6.7 6.8 6.97.1’.

In addition to a per-inferior number, each thread is alsoassigned a unique global number, also known as globalthread ID, a single integer. Unlike the thread number component ofthe thread ID, no two threads have the same global ID, even whenyou’re debugging multiple inferiors.

From GDB’s perspective, a process always has at least onethread. In other words, GDB assigns a thread number to theprogram’s “main thread” even if the program is not multi-threaded.

The debugger convenience variables ‘$_thread’ and‘$_gthread’ contain, respectively, the per-inferior thread numberand the global thread number of the current thread. You may find thisuseful in writing breakpoint conditional expressions, command scripts,and so forth. See Convenience Variables, forgeneral information on convenience variables.

If GDB detects the program is multi-threaded, it augments theusual message about stopping at a breakpoint with the ID and name ofthe thread that hit the breakpoint.

Likewise when the program receives a signal:

Display information about one or more threads. With no argumentsdisplays information about all threads. You can specify the list ofthreads that you want to display using the thread ID list syntax(see thread ID lists).

GDB displays for each thread (in this order):

1. the per-inferior thread number assigned by GDB
2. the global thread number assigned by GDB, if the ‘-gid’option was specified
3. the target system’s thread identifier (systag)
4. the thread’s name, if one is known. A thread can either be named bythe user (see thread name, below), or, in some cases, by theprogram itself.
5. the current stack frame summary for that thread

An asterisk ‘*’ to the left of the GDB thread numberindicates the current thread.

For example,

If you’re debugging multiple inferiors, GDB displays threadIDs using the qualified inferior-num.thread-num format.Otherwise, only thread-num is shown.

If you specify the ‘-gid’ option, GDB displays a columnindicating each thread’s global thread ID:

On Solaris, you can display more information about user threads with aSolaris-specific command:

Display info on Solaris user threads.

Make thread ID thread-id the current thread. The commandargument thread-id is the GDB thread ID, as shown inthe first field of the ‘info threads’ display, with or without aninferior qualifier (e.g., ‘2.1’ or ‘1’).

GDB responds by displaying the system identifier of thethread you selected, and its current stack frame summary:

As with the ‘[New …]’ message, the form of the text after‘Switching to’ depends on your system’s conventions for identifyingthreads.

Gdb For Macos

The thread apply command allows you to apply the namedcommand to one or more threads. Specify the threads that youwant affected using the thread ID list syntax (see thread ID lists), or specify all to apply to all threads. To apply acommand to all threads in descending order, type thread apply allcommand. To apply a command to all threads in ascending order,type thread apply all -ascending command.

The flag arguments control what output to produce and how to handleerrors raised when applying command to a thread. flagmust start with a - directly followed by one letter inqcs. If several flags are provided, they must be givenindividually, such as -c -q.

By default, GDB displays some thread information before theoutput produced by command, and an error raised during theexecution of a command will abort thread apply. Thefollowing flags can be used to fine-tune this behavior:

The flag -c, which stands for ‘continue’, causes anyerrors in command to be displayed, and the execution ofthread apply then continues.

The flag -s, which stands for ‘silent’, causes any errorsor empty output produced by a command to be silently ignored.That is, the execution continues, but the thread information and errorsare not printed.

The flag -q (‘quiet’) disables printing the threadinformation.

Flags -c and -s cannot be used together.

Shortcut for thread apply all -s command.Applies command on all threads, ignoring errors and empty output.

Shortcut for thread apply all -s frame apply all -s command.Applies command on all frames of all threads, ignoring errorsand empty output. Note that the flag -s is specified twice:The first -s ensures that thread apply only shows the threadinformation of the threads for which frame apply producessome output. The second -s is needed to ensure that frameapply shows the frame information of a frame only if thecommand successfully produced some output.

Gdb Machine Code

It can for example be used to print a local variable or a functionargument without knowing the thread or frame where this variable or argumentis, using:

This command assigns a name to the current thread. If no argument isgiven, any existing user-specified name is removed. The thread nameappears in the ‘info threads’ display.

On some systems, such as GNU/Linux, GDB is able todetermine the name of the thread as given by the OS. On thesesystems, a name specified with ‘thread name’ will override thesystem-give name, and removing the user-specified name will causeGDB to once again display the system-specified name.

Search for and display thread ids whose name or systagmatches the supplied regular expression.

As well as being the complement to the ‘thread name’ command, this command also allows you to identify a thread by its target systag. For instance, on GNU/Linux, the target systagis the LWP id.

The set print thread-events command allows you to enable ordisable printing of messages when GDB notices that new threads havestarted or that threads have exited. By default, these messages willbe printed if detection of these events is supported by the target.Note that these messages cannot be disabled on all targets.

Show whether messages will be printed when GDB detects that threadshave started and exited.

See Stopping and Starting Multi-thread Programs, formore information about how GDB behaves when you stop and startprograms with multiple threads.

See Setting Watchpoints, for information aboutwatchpoints in programs with multiple threads.

If this variable is set, path is a colon-separated list ofdirectories GDB will use to search for libthread_db.If you omit path, ‘libthread-db-search-path’ will be reset toits default value ($sdir:$pdir on GNU/Linux and Solaris systems).Internally, the default value comes from the LIBTHREAD_DB_SEARCH_PATHmacro.

On GNU/Linux and Solaris systems, GDB uses a “helper”libthread_db library to obtain information about threads in theinferior process. GDB will use ‘libthread-db-search-path’to find libthread_db. GDB also consults first if inferiorspecific thread debugging library loading is enabledby ‘set auto-load libthread-db’ (see libthread_db.so.1 file).

A special entry ‘$sdir’ for ‘libthread-db-search-path’refers to the default system directories that arenormally searched for loading shared libraries. The ‘$sdir’ entryis the only kind not needing to be enabled by ‘set auto-load libthread-db’(see libthread_db.so.1 file).

A special entry ‘$pdir’ for ‘libthread-db-search-path’refers to the directory from which libpthreadwas loaded in the inferior process.

For any libthread_db library GDB finds in above directories,GDB attempts to initialize it with the current inferior process.If this initialization fails (which could happen because of a versionmismatch between libthread_db and libpthread), GDBwill unload libthread_db, and continue with the next directory.If none of libthread_db libraries initialize successfully,GDB will issue a warning and thread debugging will be disabled.

Setting libthread-db-search-path is currently implementedonly on some platforms.

Display current libthread_db search path.

Install Gdb For Mac

Turns on or off display of libthread_db-related events.Use 1 to enable, 0 to disable.

Mac Gdb Codesign

Next: Forks, Previous: Inferiors and Programs, Up: Running [Contents][Index]