For my studies I have to run a binary unix-program bomb with gdb.
Some time ago I followed the steps on http://jakoblaegdsmand.com/blog/2013/04/how-to-get-an-awesome-looking-terminal-on-mac-os-x/ and made some changes to my terminal-setup.
To runbomb with gdb I typed:
-> bomb207 gdb bomb
zsh: correct 'gdb' to 'gdv' [nyae]? n
zsh: command not found: gdb
When I type 'man gdb' zsh answers 'No manual entry for gdb'
How can I change my terminal-setup to support gdb?
ps.
I already installed the command line tools for os x with x code and I didn't had any problems until now...
bomb207 is the current directory and the location of bomb.
It appears that Apple (who have been switching from gcc to clang for some time) stopped including gdb in 10.8. Even in the CommandLine tools.
The clang debugger is lldb. It is similar in use to gdb, and I'm not finding it unduly difficult to switch. Aside from explaining to my finger that they shouldn't type gdb
for the debugger anymore: my fingers don't like change.
Yes, you can still type gcc to compile things, but look:
$ gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin12.5.0
Thread model: posix
on 10.15.6+ you can simply install gdb using homebrew
brew install gdb
You need to install GNU Debugger, or GDB. Try installing the full XCode package?
GDB works fine on my Mac, but then I've got full XCode installed.
Failing that, just for my peace of mind, type 'where gdb' and tell me what it prints out?
On my Mac it's in '/usr/bin/gdb', and on my linux boxes it's in '/usr/bin/gdb' and '/usr/bin/X11/gdb'.
Related
Mac 10.13.6 High Sierra here. New to C development and I'm trying to get myself setup with the latest stable/recommended GCC version, which I believe (keep me honest here) is 10.2.
When I go to the terminal to see what I have installed:
$ gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 9.1.0 (clang-902.0.39.1)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
$ gcc -dumpversion
4.2.1
OK...surprised to see LLVM/clang-related stuff in the output. So I try this:
$ clang --version
Apple LLVM version 9.1.0 (clang-902.0.39.1)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
So its almost as if... I have both clang and gcc installed, but my clang installation has assimilated my GCC installation?! Why else would the gcc --version output reference clang?
Is this typical for Mac setups?
What do I need to do to get GCC 10.2 properly installed on my machine?
Here are some simple truths, statements and observations to try and explain what's going on:
Apple ships the clang/LLVM compiler with macOS. Clang is a "front-end" that can parse C, C++ and Objective-C down to something that LLVM (referred to as a "back-end") can compile
Clang/LLVM is located in /Applications/Xcode.app/somewhere
Apple also ships a /usr/bin/gcc which just runs clang. I have no idea why they do that - it doesn't seem very helpful to me - but they don't answer my questions
Apple puts its binaries (programs) in /usr/bin. That is an integral part of macOS and you should never touch or change anything in there - you are asking for problems if you do. This warning applies to Python too.
If you want the real, lovely GNU Compiler Collection (GCC) which includes the gcc, g++ and gfortran compilers, your best bet, IMHO, is to get them from homebrew. I will not put the installation instructions here because they could become outdated, so you should use the ones on the homebrew site.
Once you have homebrew installed, you can install the GNU Compiler Collection (GCC) with:
brew install gcc
After that, you will have all the lovely GNU Compiler Collection (GCC) of tools in /usr/local/bin, so you should put that in your PATH, near the beginning, and in any case before /usr/bin, using:
export PATH=/usr/local/bin:$PATH
In general, you should also add a similar line into your login profile, or into the system login profile, so it is set up every time you or any other user logs in.
Let's take a look:
ls /usr/local/bin/gcc* /usr/local/bin/g++*
/usr/local/bin/gcc-10
/usr/local/bin/g++-10
Depending on the versions and updates, you will then have these programs available:
gcc-10 # the real GNU C compiler
g++-10 # the real GNU C++compiler
gfortran # GNU fortran compiler
And you can check their versions with:
gcc-10 -v
g++-10 -v
gfortran -v
Now you know about homebrew, here are some more simple truths and observations:
folks (who are not the supplier of the operating system) who supply binaries (programs) for you should put their stuff in /usr/local to show that it is just a locally installed program rather than a part of the core macOS operating system
homebrew is well-behaved and installs its binaries (programs) in /usr/local/Cellar and then usually makes symbolic links from /usr/local/bin/PROGRAM to the Cellar. None of this interferes with Apple-supplied stuff.
if you want to run the homebrew version of a command, you should have /usr/local/bin first on your PATH
Let's have a look at those symbolic links:
ls -l /usr/local/bin/g*10
lrwxr-xr-x 1 mark admin 31 21 Aug 16:41 /usr/local/bin/g++-10 -> ../Cellar/gcc/10.2.0/bin/g++-10
lrwxr-xr-x 1 mark admin 31 21 Aug 16:41 /usr/local/bin/gcc-10 -> ../Cellar/gcc/10.2.0/bin/gcc-10
If you want to know what you are actually running when you enter a command, use the type command like this.
type gcc
gcc is hashed (/usr/bin/gcc)
That tells you that if you run gcc you will actually be running /usr/bin/gcc which we know is from Apple - because it is in /usr/bin
Now try this:
type gcc-10
gcc-10 is hashed (/usr/local/bin/gcc-10)
That tells you that if you run gcc-10 you will actually be running /usr/local/bin/gcc-10 which we know is from homebrew - because it is in /usr/local/bin
I get gdb by brew install gdb.
The source file content is:
#include <cstdio>
int main(){
int a = 10;
for(int i = 0; i< 10; i++){
a += i;
}
printf("%d\n",a);
return 0;
}
Here is the executable file named 'demo':
https://pan.baidu.com/s/1wg-ffGCYzPGDI77pRxhyaw
I compile the source file like this:
c++ -g -o demo demo.cpp
And run gdb
gdb ./demo
But, it can't work. It can't recognized the executable file.
GNU gdb (GDB) 8.2
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-apple-darwin18.0.0".
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"...
BFD: /Users/xxx/Codes/demo: unknown load command 0x32
BFD: /Users/xxx/Codes/demo: unknown load command 0x32
"/Users/xxx/Codes/demo": not in executable format: file format not recognized
I use file demo,its ouput is demo: Mach-O 64-bit executable x86_64
I use file ./demo,its output is ./demo: Mach-O 64-bit executable x86_64
Type c++ -v, output is :
Apple LLVM version 10.0.0 (clang-1000.10.44.2)
Target: x86_64-apple-darwin18.0.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
run ./demo,its output is 55
type show configuration in gdb,it shows:
This GDB was configured as follows:
configure --host=x86_64-apple-darwin18.0.0 --target=x86_64-apple-darwin18.0.0
--with-auto-load-dir=:${prefix}/share/auto-load
--with-auto-load-safe-path=:${prefix}/share/auto-load
--with-expat
--with-gdb-datadir=/usr/local/Cellar/gdb/8.2/share/gdb (relocatable)
--with-jit-reader-dir=/usr/local/Cellar/gdb/8.2/lib/gdb (relocatable)
--without-libunwind-ia64
--without-lzma
--without-babeltrace
--without-intel-pt
--disable-libmcheck
--without-mpfr
--with-python=/System/Library/Frameworks/Python.framework/Versions/2.7
--without-guile
--with-separate-debug-dir=/usr/local/Cellar/gdb/8.2/lib/debug (relocatable)
Who can help me ? Thank you very much !!!
The problem is that clang-1000.11.45.2 distributed with Apple LLVM version 10.0.0 adds a new load command to o-mach executables named LC_BUILD_VERSION.
$ otool -l test.o
...
Load command 1
cmd LC_BUILD_VERSION
cmdsize 24
platform macos
sdk n/a
minos 10.14
ntools 0
...
From the apple source:
/*
* The build_version_command contains the min OS version on which this
* binary was built to run for its platform. The list of known platforms and
* tool values following it.
*/
So currently bfd (the program used by gdb to manipulate executables) is not able to interpret this command and returns the error.
As a temporary solution, you can edit the bfd sources code provides with gdb.
First, download gdb-8.0.1 sources from mirrors. Then add to gdb-8.0.1/bfd/mach-o.c the following code at line 4649 :
case BFD_MACH_O_LC_BUILD_VERSION:
break;
Finally inside gdb-8.0.1/include/mach-o/loader.h at line 189:
BFD_MACH_O_LC_BUILD_VERSION = 0x32
Don't forget to add a , at the end of the line 188 after BFD_MACH_O_LC_VERSION_MIN_WATCHOS = 0x30).
Then process a classic gdb compilation following instructions from the README :
run the ``configure'' script here, e.g.:
./configure
make
To install them (by default in /usr/local/bin, /usr/local/lib, etc),
then do:
make install
Don't forget to sign gdb as explain here.
If you still get the (os/kern) failure (0x5) error, just run sudo gdb.
This is a temporary solution in order to wait for a fix from GNU team.
EDIT
Binutils-gdb has been updated, these changes are now implemented in commit fc7b364.
Hope It will be helpful.
I published a temporary brew formula that seems to work, while awaiting for official brew formula to be updated:
brew install https://raw.githubusercontent.com/timotheecour/homebrew-timutil/master/gdb_tim.rb
Upgrade to GDB version 8.3. Also see Issue 23728, binutils fail on macOS 10.14 (Mojave) due to unimpl in the Binutils bug tracker.
From the bug report:
I've found the root of the issue. binutils does not handle load
command 0x32 LC_BUILD_VERSION (nor 0x31 LC_NOTE, actually). They are
defined in recent LLVM versions: see
https://github.com/llvm-mirror/llvm/blob/master/include/llvm/BinaryFormat/MachO.def#L77
Looking at the output of objdump -private-headers there is one clear
difference:
## -56,16 +56,18 ## attributes NO_TOC STRIP_STATIC_SYMS LIVE
reserved1 0
reserved2 0
Load command 1
- cmd LC_VERSION_MIN_MACOSX
- cmdsize 16
- version 10.13
- sdk n/a
+ cmd LC_BUILD_VERSION
+ cmdsize 24
+ platform macos
+ sdk n/a
+ minos 10.14
+ ntools 0
Load command 2
cmd LC_SYMTAB
cmdsize 24
LC_VERSION_MIN_MACOSX is implemented in binutils, while
LC_BUILD_VERSION is not. It is apparently new in Mojave.
I have got a good solution for me from stack overflow and I do not know why it works.
Here is the link.
I am new to macOS, and I do the following:
Codesign gdb 8.0.1 in high Sierra
Update to Mojave
gdb 8.0.1 died with BFD: /Users/xxx/Codes/demo: unknown load command 0x32
Change to gdb 8.2.1 and come across Keychain error Unknown Error -2,147,414,007.
Solve this by getting the certificate in Login then export it and import it into System(Delete it from Login if unable to import).
Finally, because of some kind of errors it still does not work and it comes with ERROR: Unable to start debugging. Unexpected GDB output from command "-exec-run". Unable to find Mach task port for process-id 1510: (os/kern) failure (0x5).
(please check gdb is codesigned - see taskgated(8)), according to how to undo codesign, something wrong still exist and the answer tells me to brew reinstall gdb, but it still does not work, I called it a day yesterday.
Finally I come across that link, I AM HAPPYY, now I am able to debug!
Hope my solution can help.
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.20190212.tar.xz) - amongst other things, it adds handling for recognizing executables on Mac.
b) build gdb. I got errors for variable shadowing in darwin-nat.c so I edited the file and rebuilt.
c) follow steps in https://forward-in-code.blogspot.com/2018/11/mojave-vs-gdb.html
Voila.
(source: GDB on Mac/Mojave: During startup program terminated with signal ?, Unknown signal)
gdb 8.2 installed from Homebrew is not compatible with Mac mojave.
I have upgrade to 8.2.1. The issue should be resolved.
The answer by timotheecour above did work for me:
brew install https://raw.githubusercontent.com/timotheecour/homebrew-timutil/master/gdb_tim.rb
Then I had to generate a generate a self-signed certificate as in
https://www.thomasvitale.com/how-to-setup-gdb-and-eclipse-to-debug-c-files-on-macos-sierra/
I got past this issue on Mojave by thinning the app. GDB does not understand universal binaries. So if file myapp tells you myapp is a universal binary, try this:
lipo -thin x86_64 -output myapp-x86_64 myapp
And then
gdb myapp-x86_64
$ make dependencies
in my terminal on Mac gives
make: lsb_release: Command not found
Here is the full message:
make: lsb_release: Command not found
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
/bin/bash: md5sum: command not found
mldb/ext/tinyxml2//tinyxml2.mk:1: *** hash_command1 didnt set variable g++_-fPIC_-m64_-fno-omit-frame-pointer_-msse3_-msse4.2_-Imldb_-Wall_-Werror_-Wno-sign-compare_-Woverloaded-virtual_-Wno-deprecated-declarations_-Wno-deprecated_-Winit-self_-Wno-unused-but-set-variable_-Wno-psabi_-Wno-unknown-pragmas_-pipe_-ggdb_-std_c++0x_-D_GLIBCXX_USE_NANOSLEEP_1_-D_GLIBCXX_USE_SCHED_YIELD_1_-fno-builtin-malloc_-fno-builtin-calloc_-fno-builtin-realloc_-fno-builtin-free_-o_build/x86_64/obj/mldb/ext/tinyxml2/tinyxml2.cpp.lo_-c_./mldb/ext/tinyxml2/tinyxml2.cpp_-MP_-MMD_-MF_build/x86_64/obj/mldb/ext/tinyxml2/tinyxml2.cpp.d_-MQ_build/x86_64/obj/mldb/ext/tinyxml2/tinyxml2.cpp.lo_-O3_-DBOOST_DISABLE_ASSERTS_-DNDEBUG_hash. Stop.
I have GNU Make 3.81 installed. Also, I did:
$ xcode-select -p
/Applications/Xcode.app/Contents/Developer
$ gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 7.3.0 (clang-703.0.29)
Target: x86_64-apple-darwin15.3.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
I am on a Mac OS X. It could be linked to zsh since I installed it not too long ago and I believe that all my xcode related tools worked just fine before.
Thanks for any help or indication that can point me in the right direction to fix this.
Update
c++ code that I was trying to build is for ubuntu 14
lsb_release is a command that runs on Linux only: the "LSB" stands for "Linux Standard Base" and this refers to a standard baseline set of tools and libraries that Linux distributions can elect to support.
Your makefile should not be invoking that command, since it's not portable to OS X. I'd say that whatever code you're trying to build is not ported to OS X and will only build on Linux. But since you didn't provide any other details, we can't say for sure.
I somehow lost the man pages for gcc and g++. I'm not sure where/what to look for. I'm pretty sure the man pages used to work some time ago. It also works on my Mac at work where I use roughly the same setup. Could it be a problem with brew? Or is it a bug in the XCode Command Line Tools?
Update: I just tried to re-install the XCode Command Line Tools. No luck.
~
✓ man gcc
No manual entry for gcc
~
✗ which gcc
/usr/bin/gcc
~
✓ gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin13.1.0
Thread model: posix
gcc isn't installed anymore by Xcode, it really installs clang and calls it gcc
usxxplayegm1:~ grady$ which gcc
/usr/bin/gcc
usxxplayegm1:~ grady$ /usr/bin/gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.1 (clang-503.0.38) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin13.0.2
Thread model: posix
you need man clang
I thought it was a symlink, but ls -l doesn't list it as a symlink, so either it is a hard link or some other sort of trickery.
This may be old and doesn't quite answers your concrete question, but I found myself in the same problem with Kali Linux and I solved it with this command, maybe is useful for someone:
apt install gcc-doc
Look at how you set MANPATH in your .profile. Instead of, e.g.,
export MANPATH=/opt/local/man:/usr/local/man
you should do
export MANPATH="/opt/local/man:/usr/local/man:$MANPATH"
And then (breathe) open a new Terminal window.
This way your .profile isn't wiping out (or reflecting an old version of) the system's way of setting MANPATH, which is modified when you install (or reinstall) Xcode.
I use High Sierra with g++ 7.2 port. Setting MANPATH environment to /opt/local/man (or to /opt/local/man/man1 where g++.gz is found) did not work. So, after ensuring that the soft link g++.gz points to g++-mp-7.1.gz (there was not a g++-mp-7.2.gz in the man1 directory though g++7.2 is my version), I always use the command:
man /opt/local/share/man/man1/g++.gz
that never fails. You can store an alias for this in your .profile, if you are frequently using the man command for g++.
For anyone who stumbles upon this currently (like I did), I found that I needed to locate my version of gcc (which I had installed with brew). This is annoying when gcc --version gives the clang version instead! To find the correct gcc version, run
$ ls /usr/local/opt/gcc/bin | grep gcc
gcc-10
gcc-ar-10
gcc-nm-10
...
So I had gcc-10. Whenever you wish to use gcc just replace it with gcc-10, e.g. man gcc-10. Of course you could write an alias for gcc to gcc-10, but this probably is not a great idea, as Xcode seems to rely on the gcc --> clang (hard?) link.
I've been trying to find an answer to this on stackoverflow for about an hour now, seems that a lot of similar problems are around but none really fitting to mine.
Information about what tools I'm using can be found further down!
I am writing my own compiler for a subset of the java language and thus creating assembler code. Now I'm at a point where I need to debug said assembler code to locate a bug. The problem is when I compile my assembler code to a binary with gcc -m32 -g myAssembler.s I get the following warning:
warning: no debug symbols in executable (-arch i386)
(This warning also occurs using -ggdb, -ggdb2, -ggdb3, -g2, -g3instead of -g
Since there are no debug symbols I can't use gdb to debug my code. I don't know much about linking and how it's done or who does it (especially on a Mac), so precise/noob-friendly answers would be very welcome.
Tools I'm using:
The assembly created from my compiler is x86, 32-bit GAS Syntax.
I am using OS X Mavericks with GNU gdb (GDB) 7.6 downloaded via MacPorts (They changed its name to ggdb. The ggdb --version command shows also a line saying :
This GDB was configured as "x86_64-apple-darwin13.0.0".
(Not quite sure if that's important.)
Running gcc --version returns:
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin13.0.0
Thread model: posix
This is probably connected with Apple dropping support for GDB in Xcode 5 and you are using the version of gcc that comes with Xcode 5. You probably need to change compiler or debugger (to lldb)… you might look at llvm-gcc (which Xcode 5 also drops support for). Try www.llvm.org for a download. But that might be more trouble than using lldb (if your problem is indeed connected to Xcode 5's changes). Good luck! – CRD
I just downloaded gcc-4.2 from homebrew and that seems to work for lldb (which is still supported by Xcode 5 it seems). – Octoshape