4

it's my first post so I apologise in advance if I post anything wrong or incorrectly format.

My system: MacBook Pro running MacOS Mojave 10.14.1, Netbeans 8.2

I'm running a simple C++ program that prints hello world:

int main(int argc, char** argv) {

    cout << "Hello World" << endl;

    return 0;
}

So my issue is that I cannot run the debugger on my MacBook using Netbeans or Terminal commands. Every time I do, I get the following error:

not in executable format: file format not recognized

I originally had the problem where I had a missing debugger command. I followed the directions here and installed Homebrew, got gdb, and code-signed the gdb binary. After all that I started getting the error highlighted above.

I google this new problem, and I find this stack overflow post which suggests that I might be running a 32-bit gdb while building in 64-bit. However, based on the output when running gdb:

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/Anon/Desktop/gdb_test/gdb_test: unknown load command 0x32
BFD: /Users/Anon/Desktop/gdb_test/gdb_test: unknown load command 0x32
"/Users/Anon/Desktop/gdb_test/gdb_test": not in executable format: file format not recognized

And the configuration of the GDB:

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)

("Relocatable" means the directory can be moved with the GDB installation tree, and GDB will still find it.)

It seems that my GDB is indeed 64-bit so I'm guessing that's not the problem. I also found this post where the top answer suggests that gdb 8.2 is impossibly broken and I should just downgrade to 8.0.1. However, an edit says that an update by the GNU team has (supposedly) fixed the problem so I run:

brew update

and ensure that everything is up-to-date, but I still get the same error.

I'm at my wits end here, and I've put in WAY too much time into trying to resolve this issue. If it can't be fixed, can you suggest other hassle-free ways (massive emphasis on hassle-free) I can debug C/C++ programs on my Mac? Otherwise, I'll stick to my university's computer labs.

EDIT: here's how I compiled from the terminal

g++ -g main.cpp -o main

I'm compiling in Debug mode (64-bit) in Netbeans with C++14 standard using the g++ compiler.

I call gdb after compiling by writing to the terminal:

gdb main

or by simply using the GUI in Netbeans

user510963
  • 51
  • 1
  • 3
  • 1
    Come on! It's pretty fundamental how you compiled the program (i.e. which compiler and which switches) and how you tried to start `gdb` - you need to click `edit` under your post and add that. – Mark Setchell Nov 17 '18 at 18:47
  • If you can't get it working on your Mac, the other options are to `ssh` into your University computers, take a free Amazon E2C Linux instance and connect to that and compile there which you can do from Uni or home, or install VirtualBox on your Mac and then a Linux Virtual Machine on there. – Mark Setchell Nov 17 '18 at 18:50
  • @MarkSetchell thanks for the suggestion, though I already remote login when I need to. It's just not so convenient – user510963 Nov 17 '18 at 21:52
  • @eukaryota sorry about that, I've made an edit at the end and added how I compiled and called gdb. Any help is appreciated – user510963 Nov 17 '18 at 21:54
  • Try running `which g++` to see what you are actually running. – Mark Setchell Nov 17 '18 at 21:54
  • After running `which g++` I get `/usr/bin/g++`. I also ran `which gdb` and got `/usr/local/bin/gdb`. Is this a problem since it's one is in a `local` directory? – user510963 Nov 17 '18 at 22:03
  • I had time to check my answer this morning and it does not solve the issue. Something else has changed that I do not know about, so I have deleted my answer. Maybe someone clever @bfontaine will have some insights to share. – Mark Setchell Nov 18 '18 at 11:26
  • 1
    should we close as duplicate of https://stackoverflow.com/questions/52529838/gdb-8-2-cant-recognized-executable-file-on-macos-mojave-10-14 ? – timotheecour Dec 03 '18 at 00:31
  • 1
    Possible duplicate of [gdb 8.2 can't recognized executable file on macOS Mojave 10.14](https://stackoverflow.com/q/52529838/608639). Also see [Issue 23728, binutils fail on macOS 10.14 (Mojave) due to unimpl](https://sourceware.org/bugzilla/show_bug.cgi?id=23728) in the Binutils bug tracker. You need GDB 8.3. – jww Dec 03 '18 at 06:08

1 Answers1

1

The compilers on macOS are confusing. Apple supplies the LLVM compiler as part of Xcode, but it provides a stub at /usr/bin/g++ which leads people to believe they are using GCC, i.e. the GNU Compiler Collection. They then try to use gdb, i.e. the GNU Debugger with the LLVM-produced executables and find it doesn't work.

IMHO, you either need to use wholly Apple-supplied tools, or wholly GNU-supplied tools.


So, let's look at the first option - using Apple tools. In this case you compile with:

/usr/bin/g++ -g main.cpp -o main

and debug with:

/usr/bin/lldb ./main

and the debugger commands seem pretty similar to GDB.


The second option is using GCC and GDB which are normally best installed using homebrew. The installation commands are:

brew install gcc
brew install gdb

Then you will compile with something like:

/usr/local/bin/g++-8 -g main.cpp -o main

and debug with something like:

/usr/local/bin/gdb ./main

However, I cannot get this to work on macOS Mojave for the moment! I read here that GDB v8.1 doesn't work on macOS and you need to install v8.0.1 instead but cannot seem to do that with homebrew.

Mark Setchell
  • 191,897
  • 31
  • 273
  • 432
  • 1
    After running `g++ -v` I get `Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include/c++/4.2.1 Apple LLVM version 10.0.0 (clang-1000.10.44.4) Target: x86_64-apple-darwin18.2.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin` But I still get the same error after installing gcc and compiling/debugging like you said – user510963 Nov 17 '18 at 22:24
  • gdb works perfectly well with LLVM-built executables, and with programs written in assembly, and with binaries directly created in machine code by flipping bits on your hard disk with a fridge magnet. If it runs, you should be able to run it in (non-broken) gdb. You may or may not get symbolic debugging, but that's not what this question is about. – n. m. could be an AI Dec 03 '18 at 06:21