No function name in stack trace, GDB, but appears in LLDB [duplicate]

Question

I'm currently trying to test out a Vector class implementation, and am trying to use GDB to see where the error happens.

When I compile with the following gcc -ggdb Vector.c TestVector.c, and subsequently run it in GDB, I get the following as output (after crashing and attempting to print the stack trace):

| => gdb ./a.out
Reading symbols from ./a.out...Reading symbols from /Users/prog/Desktop/Generics/a.out.dSYM/Contents/Resources/DWARF/a.out...done.
done.
(gdb) r
Starting program: /Users/prog/Desktop/Generics/a.out
[New Thread 0x2703 of process 56984]
warning: unhandled dyld version (15)

Thread 2 received signal SIGSEGV, Segmentation fault.
0x00007fff65d97fe6 in ?? ()
(gdb) bt
#0  0x00007fff65d97fe6 in ?? ()
#1  0x00007ffeefbff640 in ?? ()
#2  0x00007fff65be4139 in ?? ()
#3  0x00007ffeefbff660 in ?? ()
#4  0x0000000000000000 in ?? ()

which is not particularly helpful in figuring out where the error is due to the backtrace only showing the absolute memory locations of my function's execution.

When I perform the same task in LLDB, the output is a bit clearer:

My question is, why does gdb not give me accurate information and lldb does (despite me not changing compilation settings between the two debugging sessions), and how can I fix this?

If it's of any help, I am using Mac OS X, High Sierra as my operating system.

Answer 1

The gdb you're using doesn't recognize the shared libraries being loaded into the process by dyld. Notice at the top of your gdb output it says "unhandled dyld version (15)". It looks like the gdb you're using needs to be updated to work correctly on macOS. I'm not sure how actively maintained the macOS port of gdb is these days.