Does gdb work in macOS Big Sur? I followed all installation instructions and got it codesigned. After I load a very simple code that's supposed to add two variables, it hangs forever after I set a breakpoint and type "run" (see output below). I have even tried to compile gdb from source.
Reading symbols from ./a.out...
Reading symbols from /Users/andya/Downloads/a.out.dSYM/Contents/Resources/DWARF/a.out...
(gdb) b 6
Breakpoint 1 at 0x100003e2f: file aa.f90, line 6.
(gdb) run
Starting program: /Users/andya/Downloads/a.out
[New Thread 0x5403 of process 45117]
Related
I'm having this "issue" with gcc and gdb, which by itself isn't a real problem but it still annoys me and I want to understand why it's happening and how to solve it. First I want to apologize because English is not my native language.
tl;dr: When I debug a file compiled with the MSYS2 MinGW-w64 gcc and I get to the last line of main and click 'Step over' (on VS code) or type the 'next' command (running gdb on the shell) I get an error indicating that the file 'crtexe.c' cannot be opened or be found. It doesn't cause me any trouble but it's annoying. Also, it doesn't happen when the official MinGW-w64 gcc compiler is used instead.
To put you in context, I'm doing the Harvard's CS50 course but I always want to dig deeper and end up spending much more time in topics don't covered by the course itself, so now I'm on Windows 10 with MSYS2, Mingw-w64, and VS Code installed. In the beginning, I started only with MinGW-w64 that I downloaded from the official website but then I realized that gcc was outdated and that installing libraries was quite complicated. So after some Google searches, I discarded the 'official' MinGW-w64 and ended up with MSYS2 and the MinGW-w64 built by them. I had the task.json, launch.json, and c_cpp_properties.json from VS Code already set up so I only changed the paths to gcc and gdb of MSYS2 and I was good to go.
But now I've noticed an error that wasn't happening before with the 'official' version of MinGW-w64. When I'm debugging a program (as simple as a 'helloworld') and I get to the last line of main (the final curly bracket) and click 'Step Over', this error message appears in VS Code:
I need to press 'Step Over' again (and receive the same error message again) two more times to finally end the program.
At first, I thought it was VS Code fault so I ran gdb directly from the shell and stepped over the code with the 'next' command, and I got the same error at the end:
(gdb) next
Hello world!6 }
(gdb) next
__tmainCRTStartup ()
at D:/mingwbuild/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:337
337 D:/mingwbuild/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c: No such file or
directory.
(gdb) next
338 in D:/mingwbuild/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c
(gdb) next
[Thread 4232.0x1a94 exited with code 0]
[Inferior 1 (process 4232) exited normally]
That made me think it was gdb the one causing the problem. But finally, after testing with both gcc and gdb from both the official MinGW-w64 and MSYS2's MinGW-w64 I concluded that the one with the issue was MSYS2 MinGW-w64 gcc. I can compile with the official mingw-w64 gcc and debug with gdb of msys2 and it works fine. But in reverse, if I compile with MSYS2 MinGW-w64 gcc and debug with the official MinGW-w64 gdb, the problem appears again.
When I compile using the official MinGW-w64 gcc and then debug it, the final gdb lines are these:
Hello world!6 }
(gdb) next
0x00000000004013c7 in __tmainCRTStartup ()
(gdb) next
Single stepping until exit from function __tmainCRTStartup,
which has no line number information.
[Thread 9436.0x1748 exited with code 0]
[Inferior 1 (process 9436) exited normally]
which doesn't translate into an error message in VS Code.
As I understand, that function (__tmainCRTStartup) is the one that starts every C program and also kills the process when it's over. I know I can simply ignore that error. But I hate error messages hehe. Besides, why if I'm stepping over the code, the debugger tries to step into that function's source code? I'd understand if I'm trying to step into, but that's not the case. Why is this happening and what can I do to fix it? (besides clicking 'Continue' instead of 'Step Over' when I'm at the end of main).
Thank you!
I wrote a simple C program to print hello world. Then I ran it through
aarch64-linux-gnu-gcc -ohello hello.c -static -g3
gdb-multiarch hello
After this, I run and gdb encounters an internal error:
Reading symbols from hello...done.
(gdb) r
Starting program: /home/gt/hello
/build/gdb-GT4MLW/gdb-8.1/gdb/i387-tdep.c:592: internal-error: void i387_supply_fxsave(regcache*, int, const void*): Assertion `tdep->st0_regnum >= I386_ST0_REGNUM' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
Here's the output of file hello:
hello: ELF 64-bit LSB executable, ARM aarch64, version 1 (GNU/Linux), statically linked, for GNU/Linux 3.7.0, BuildID[sha1]=a...b, with debug_info, not stripped
This is my hello.c:
#include<stdio.h>
int main(){
printf("hello world");
return 0;
}
What am I doing wrong? What else do I need to do? I am running Ubuntu 18.04 on an x86_64 machine.
When I use gdb hello, I am unable to use breakpoints, I get this error:
Reading symbols from hello...done.
(gdb) break 4
Breakpoint 1 at 0x400404: file hello.c, line 4.
(gdb) r
Starting program: /home/gt/hello
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x400404
(gdb)
I am following the guide given on this page under the first section.
In order to run and debug your AArch64 executable, you (in general) need to run it on an AArch64 machine, or in an AArch64 emulator.
You might have some setup where qemu more or less transparently emulates aarch64 binaries for you - but that doesn't work quite as transparently for the debugger. In general you can run the debugger on one machine, connected over a network to a debugging server on a different machine, allowing you to debug a process running on the machine with the debugging server.
The guide you linked shows how to set up qemu to allow it to transparently emulate binaries as you execute them. That guide only shows executing, not debugging, but it has got a link "Debugging using GDB" that points to https://ubuntuforums.org/showthread.php?t=2010979&s=096fb05dbd59acbfc8542b71f4b590db&p=12061325#post12061325, where it is explained how to debug a process which executes within qemu emulation. This essentially amounts to the same remote debugging with a debugging server as I mentioned above.
The essential bits of this post is this:
# In a terminal
$ qemu-arm-static -g 10101 ./hello
# In a new terminal
$ gdb-multiarch
(gdb) target remote :10101
Remote debugging using :10101
[New Remote target]
[Switching to Remote target]
I have clang++ 4.1
clang++ -v
Apple clang version 4.1 (tags/Apple/clang-421.11.66) (based on LLVM 3.1svn)
Target: x86_64-apple-darwin11.4.2
Thread model: posix
I also have lldb 167.5
lldb -v
LDB-167.5
I compiled simple c++ code with this command.
clang++ testit.cpp -std=c++11 -stdlib=libc++ -g -o a
When I tried to debug it with lldb, I executed lldb ./a, set break point with b main and run.
lldb) r
Process 44582 launched: '/Users/smcho/Desktop/cpp11/lldb/a' (x86_64)
Process 44582 stopped
* thread #1: tid = 0x1f03, 0x00000001000007e8 a`main [inlined] std::__1::__vector_base<std::__1::unique_ptr<A, std::__1::default_delete<A> >, std::__1::allocator<std::__1::unique_ptr<A, std::__1::default_delete<A> > > >::__vector_base() at vector:460, stop reason = breakpoint 1.1
frame #0: 0x00000001000007e8 a`main [inlined] std::__1::__vector_base<std::__1::unique_ptr<A, std::__1::default_delete<A> >, std::__1::allocator<std::__1::unique_ptr<A, std::__1::default_delete<A> > > >::__vector_base() at vector:460
457 _NOEXCEPT_(is_nothrow_default_constructible<allocator_type>::value)
458 : __begin_(0),
459 __end_(0),
-> 460 __end_cap_(0)
461 {
462 }
463
The C++ source code is in this post: How to print out the content in vector<unique_ptr> with gdb on Mac OS X
What might be wrong?
Nothing is specifically wrong.
You are using libc++ which does heavy inlining (even at -O0, yes) - that means your code in main() is interleaved with libc++ code
The first step in your main() is to create a std::vector, and indeed you are stopped in the (inlined) constructor for std::vector (its base class, namely). It simply happens to be the first "user" instruction in your call.
You should be able to "next" over it to your user-level code.
One thing to be aware of is that you're using an older version of clang and lldb. With Xcode 4, when you run
% lldb
You're running lldb from /usr/bin which is installed by the "Command Line Tools" package (an optional download, either from developer.apple.com or from within Xcode - Preferences > Downloads tab > Components). If you instead do
% xcrun lldb
You'll be running the lldb which is included in Xcode.app -- expect to see a version like lldb-179.6. There were some important improvements to the handling of inlined functions (like those in the standard C++ library) in lldb-179 and I think it may help with what you're seeing.
You can also update to the latest Command Line Tools package from within Xcode. It isn't automatically updated by the Mac App Store updates when new Xcode updates are downloaded.
Note that in this particular case your function opens with
main() {
vector<unique_ptr<A>> v;
the inlining for this ctor on the first line of the function means you're going to see this header file even with the latest tools -- the line table output by clang doesn't give the debugger the information it needs to skip over it. If you just type next or n, you'll be on the next source line of your function.
I wrote a CUDA application that has some hardcoded parameters in it (via #defines). Everything seemed to work right, so I tried some other parameters. Now, the program doesn't work correctly anymore.
So, I want to debug it. I compile the application with -deviceemu -g -O0 options, because I read that I can then use gdb to debug it. In gdb, I set a breakpoint at the kernel start using break kernelstart.
However, gdb, jumps at the start of my CUDA kernel, but I can not step through it, because it doesn't let me inspect things within the kernel. I think it's best if I give the output of gdb:
Breakpoint 1, kernelstart (__cuda_0=0x100000, __cuda_1=0x101000, __cuda_2=0x102000, __cuda_3=0x102100) at cudatest.cu:287
(gdb) s
__device_stub__Z12kernelstartPjS_S_S_ (__par0=0x100000, __par1=0x101000, __par2=0x102000, __par3=0x102100) at /tmp/tmpxft_000003c4_00000000-1_cudatest.cudafe1.stub.c:7
7 /tmp/tmpxft_000003c4_00000000-1_cudatest.cudafe1.stub.c: No such file or directory.
in /tmp/tmpxft_000003c4_00000000-1_cudatest.cudafe1.stub.c
(gdb) s
cudaLaunch<char> (entry=0x804a98d "U\211\345\203\354\030\213E\024\211D$\f\213E\020\211D$\b\213E\f\211D$\004\213E\b\211\004$\350\r\377\377\377\311\303U\211\345\203\354\070\307\004$\340 \005\b\350\345\341\377\377\243P!\005\b\307\004$x\234\004\b\350\b\001") at /usr/local/cuda/bin/../include/cuda_runtime.h:773
(gdb) s
(gdb) s
cudatest (__cuda_0=0x100000, __cuda_1=0x101000, __cuda_2=0x102000, __cuda_3=0x102100) at cudatest.cu:354
(gdb) s
After, this, it jumps back to my main procedure.
I know that my specifications are more than vague, but can anybody guess where the problem is? Is it possible to inspect kernels using gdb?
Use cuda-gdb
Compile: nvcc -g -G filename.cu
Invoke cuda-gdb on your a.out
You can set breakpoint inside your kernel function as usual.
Run the program, and it should stop inside your kernel function.
You can even get details of the current thread which is being executed using commands like cuda thread. Other commands like cuda block exist.
To switch between threads say cuda thread (x,y,z)
For more details refer to the latest version of cuda-gdb's documentation. If you are using the latest version of cuda toolkit (ie, 3.2 as of today), make sure you are looking at the latest version of the documentation (as the options have changed a lot).
And also make sure you are running cuda-gdb from a console (outside X11), since you are stopping your GPU for debugging.
Hope this helps.
Compiling with :
nvcc -g -G --keep
fixed this problem for me. This ensures all the intermediate files generated during compilation are not erased so that the debugger can find them.
I wrote a very simple Qt program here:
int main(int argc, char* argv[])
{
QApplication app(argc, argv);
QTableView table(&frame);
table.resize(100, 100);
table.show();
return app.exec();
}
And when I try to set a breakpoint where the table gets clicked, I get this error from gdb:
(gdb) symbol-file /usr/lib/libQtGui.so.4.4.3.debug
Load new symbol table from "/usr/lib/libQtGui.so.4.4.3.debug"? (y or n) y
Reading symbols from /usr/lib/libQtGui.so.4.4.3.debug...done.
(gdb) br 'QAbstractItemView::clicked(QModelIndex const&)'
Breakpoint 1 at 0x5fc660: file .moc/release-shared/moc_qabstractitemview.cpp, line 313.
(gdb) run
Starting program: ./qt-test
Warning:
Cannot insert breakpoint 1.
Error accessing memory address 0x5fc660: Input/output error.
Does anyone know why the breakpoint can't be inserted?
Don't use the gdb command symbol-file to load external symbols. The breakpoint addresses will be wrong since they're not relocated.
Instead, put a breakpoint in main, run the program, and then set your breakpoint:
gdb ./program
GNU gdb 6.8-debian blah blah blah
(gdb) br main
Breakpoint 1 at 0x80489c1
(gdb) run
Starting program: ./program
Breakpoint 1, 0x080489c1 in main ()
(gdb) br 'QAbstractItemView::clicked(QModelIndex const&)'
Breakpoint 2 at 0xb7d24664
(gdb) continue
Continuing.
Then make your breakpoint happen.
Make sure to specify the parameter list in the function you want to set a breakpoint in, without the names of those parameters, just their types.
The actual error:
Error accessing memory address 0x5fc660: Input/output error.
Can be caused by 32/64 bit mixups. Check, for example, that you didn't attach to a 32-bit binary with a 64-bit process' ID, or vice versa.
If you want to automatically break in main without setting a breakpoint you can also use the start command.
If you need to provide any arguments to the program you can use:
start argument1 argument2
OK for me I got this when building with mingw-w64 (native or cross compiler).
I'm not sure what the exact problem was, but if I build it using gcc mingw-w64 i686-5.1.0-posix-sjlj-rt_v4-rev0 then it creates (finally) debuggable builds. Otherwise
(gdb) break main
...
(gdb) r
...
Cannot insert breakpoint 1.
Cannot access memory at address 0x42445c
<process basically hangs>
message 19 times out of 20, though sometimes it did actually work (very rarely).
gdb 7.8.1 and 7.9.1 seemed to be able to debug the created exe. So it's probably not the version of gdb that makes a difference.
My current theory/suspect is either it was the version of gcc or possibly the sljl vs. dwarf2 "aspect" to the compiler [?] (i686-492-posix-dwarf-rt_v3-rev1 didn't work, and cross compiling with some form of gcc 4.9.2 didn't either). Didn't try other versions of gcc.
update: newer gcc (5.1.0) but cross compiling I still got this failure. The cause in this case turned out to be a dependency library that my build (FFmpeg) was using by linking against (libgme in this case) which is exporting a few errant "shared" symbols (when I am building a static executable). Because of this, "shared" builds brake (https://trac.ffmpeg.org/ticket/282) and somehow it screws up gdb as well. For instance possibly linking against SDL can do this to you as well. My thought is possibly an ld bug [?]