I am trying to debug AVX-512 instructions on an emulated CPU using Intel® Software Development Emulator but it doesn't work as desired after setting a breakpoint. I followed this blog post: Debugging Emulated Code on Linux*
In window #1:
~$ g++ -g -O0 -mavx512f main.cpp -o main # compile main.cpp file
~$ sde -debug -- ./main # enable debugging
Application stopped until continued from debugger.
Start GDB, then issue this command at the (gdb) prompt:
target remote :54105
In window #2
# run debugger
~$ gdb ./main
GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2
Copyright (C) 2020 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-linux-gnu".
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"...
Reading symbols from ./main...
# set target "target remote :portnumber"
(gdb) target remote :54105
Remote debugging using :54105
warning: remote target does not support file transfer, attempting to access files from local filesystem.
Reading symbols from /lib64/ld-linux-x86-64.so.2...
(No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
0x00007fa7bbbcc100 in ?? () from /lib64/ld-linux-x86-64.so.2
# suspend program at main function
(gdb) break main
Breakpoint 1 at 0x2c9c: file /home/borrow/source/repos/se-test/main.cpp, line 165.
# start program execution from the beginning of the program
(gdb) run
The "remote" target does not support "run". Try "help target" or
"continue".
# step to next line of code
(gdb) step
Cannot find bounds of current function
# continue executing until next break point
(gdb) c
Continuing.
warning: Probes-based dynamic linker interface failed.
Reverting to original interface.
[Inferior 1 (Remote target) exited normally]
In window #2: as you can see
gdb run should run a program but it doesn't work. gdb c should also run until the next breakpoint but executes the program and terminates. This command gives me the following warning message:
warning: Probes-based dynamic linker interface failed.
In window #1: The program runs and ends (without stopping).
Program code looks like this:
// main.cpp
#include <immintrin.h>
const int N=64;
int64_t srcA[N] = {0};
int64_t srcB[N] = {0};
int64_t dst[N] = {0};
void foo()
{
__m512i result,B,C;
for ( int i=0; i<N; i+=8 ){
B = _mm512_loadu_si512(&srcA[i]);
C = _mm512_loadu_si512(&srcB[i]);
result = _mm512_add_epi64(B,C);
_mm512_storeu_si512(&dst[i], result);
}
}
int main() {
...
foo();
...
}
I tried running AVX2 code without SDE emulator using gdb and it worked. First I start it on an emulated CPU with SDE, it fails. How can I solve this problem?
It seems to be broken for PIE executables
(confirmed on Arch GNU/Linux with GCC 10.2, GDB 10.1, SDE 8.33.)
Build with g++ -O2 -fno-pie -no-pie -g -march=skylake-avx512 and everything works. (I had to run gdb ./a.out instead of bare GDB; without that it couldn't find the right file even after connecting to the remote.)
$ g++ -O2 -march=skylake-avx512 -no-pie -fno-pie -g avx512.cpp
$ /opt/sde-external-8.33.0-2019-02-07-lin/sde64 -debug -- ./a.out
Application stopped until continued from debugger.
Start GDB, then issue this command at the (gdb) prompt:
target remote :59783
Then in another terminal tab
$ gdb ./a.out
...
(gdb) target remote :59783
warning: remote target does not support file transfer, attempting to access files from local filesystem.
Reading symbols from /lib64/ld-linux-x86-64.so.2...
(No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
0x00007f4f7033b090 in _start () from /lib64/ld-linux-x86-64.so.2
(gdb) b main
Breakpoint 1 at 0x401050: file avx512.cpp, line 29.
(gdb) b foo
Breakpoint 2 at 0x401190: file avx512.cpp, line 14.
(gdb) c
Continuing.
Breakpoint 1, main () at avx512.cpp:23
(gdb) layout asm
(copy-paste of some of the disassembly window)
│B+ 0x401120 <_Z3foov> xor eax,eax
│ 0x401122 <_Z3foov+2> nop WORD PTR [rax+rax*1+0x0]
│ >0x401128 <_Z3foov+8> vmovdqu64 zmm1,ZMMWORD PTR [rax+0x404260]
│ 0x401132 <_Z3foov+18> add rax,0x40
│ 0x401136 <_Z3foov+22> vpaddq zmm0,zmm1,ZMMWORD PTR [rax+0x404420]
│ 0x401140 <_Z3foov+32> vmovdqu64 ZMMWORD PTR [rax+0x404020],zmm0
│ 0x40114a <_Z3foov+42> cmp rax,0x200
│ 0x401150 <_Z3foov+48> jne 0x401128 <_Z3foov+8>
│ 0x401152 <_Z3foov+50> vzeroupper
│ 0x401155 <_Z3foov+53> ret
(gdb) layout src
asm-level and source-level debugging both work fine, stepping into intrinsic "functions" in avx512fintrin.h and so on when using stepi (aka si).
Without specifying the filename separately from connecting to the remote:
$ gdb
(gdb) target remote :46879
Remote debugging using :46879 warning: No executable has been specified and target does not support determining executable automatically. Try using the "file" command.
0x00007f0f85830090 in ?? ()
(gdb)
(IDK if it matters that my .gdbinit includes layout reg, the full-screen terminal TUI mode. Nice when it works but somewhat buggy.)
Or as a super hacky workaround with PIE executables, I was also able to put a delay loop at the top of main, giving you a chance to attach and then control-C before SDE finishes executing your program.
Then I could set breakpoints and start single-stepping. (Presumably a sleep or read system call would work). Source-level debugging still seemed broken, but I was able to debug the asm with layout reg. I used set $rip = ... with a copy-pasted address to get out of the _mm_pause() loop after attaching and hitting control-C.
Related
The following workflow worked for me at one point, and then it suddenly stopped working. I'd like to figure out why and get it to work again.
on the host, build binary for target system with debug information
send the stripped version of the binary to the target system
on the target, run the binary with gdbserver :6006 mybinary args...
on the host, run gdb-multiarch mybinary. This is the unstripped version. It shows that it loaded symbols from the local binary.
At the gdb prompt, run target remote <ip_of_target>:6006
Then, if I say b main, it inserts a breakpoint at an unrelocated address like 0x621730, which is the offset of the main function in the local binary, whereas it should be added on top of the VM address the remote binary is loaded at (0x5555555000 in this case.) Obviously the unrelocated address doesn't work.
So step 6 was working at one point. I don't know what I'm doing now differently to make the relocation no longer work. Help would be appreciated.
Version of gdbserver and that of host gdb are both Ubuntu 8.1.1-0ubuntu1. The remote system is aarch64.
So step 6 was working at one point. I don't know what I'm doing now differently to make the relocation no longer work.
I suspect that you have upgraded your toolchain, and that your upgraded toolchain produces a Position-Independent Executable mybinary by default, where the old toolchain didn't.
Try adding -no-pie to the link line of mybinary.
Obviously the unrelocated address doesn't work.
Actually, this does work for local debugging -- GDB is smart enough to realize that the code got loaded at a different address:
gdb -q a.out
Reading symbols from a.out...
(gdb) b main
Breakpoint 1 at 0x112d: file t.c, line 1. <<< Note: unrelocated address
(gdb) run
Starting program: /tmp/a.out
Breakpoint 1, main () at t.c:1
1 int main() {return 0; }
(gdb) p/x $pc
$1 = 0x55555555512d <<< Note: breakpoint worked.
It's possible that remote debugging doesn't work, although this worked fine for me using GDB-10.0:
strip a.out -o b.out
gdbserver :6006 ./b.out
Process ./b.out created; pid = 239653
Listening on port 6006
... in another window:
gdb -q ./a.out
Reading symbols from ./a.out...
(gdb) target remote :6006
Remote debugging using :6006
Reading /lib64/ld-linux-x86-64.so.2 from remote target...
warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
Reading /lib64/ld-linux-x86-64.so.2 from remote target...
Reading symbols from target:/lib64/ld-linux-x86-64.so.2...
Reading symbols from /usr/lib/debug/.build-id/a8/97a1105e21dd270bd418fe58c441700a6d8ec5.debug...
0x00007ffff7fe4940 in _start () from target:/lib64/ld-linux-x86-64.so.2
(gdb) b main
Breakpoint 1 at 0x55555555512d: file t.c, line 1.
I compiled gdbserver 7.6 for arm with:
cd /gdb-7.6-src/gdb/gdbserver
./configure --target=arm-linux --host=arm-linux
make CC=/path/to/cross-compiler-gcc
Then I compiled gdb 7.6 for arm with:
cd /gdb-7.6-src/
./configure --target=arm-linux --prefix=/opt/gdb-arm/install/
make && make install
I compiled my trivial application with:
/path/to/cross-compiler-gcc hello.c -g -o hello
I copied gdbserver and my cross-compiled application on my board.
From my pc (x86-pc-linux) I run:
gdb hello
(gdb) set target-async on
(gdb) tvariable $c
(gdb) actions
>teval $c=$c+1
>end
(gdb) break main
(gdb) target remote <ipaddr>:<port>
[Thread 1585] #1 stopped.
0x40000800 in ?? ()
Cannot access memory at address 0x0
(gdb) continue &
(gdb) tstart
Target does not support this command.
(gdb) tstatus
Target does not support this command.
The behaviour is 'normal' until the tstart command: I can debug the application as I want, but I am unable to start tracing the app.
The question is: does gdbserver support tracepoints for arm or only for x86/amd_64?
I was searching samething, what I've found in GDB online docs webdocs that there is no support for now to any Archs.
Check for more info:
https://sourceware.org/gdb/onlinedocs/gdb/Tracepoints.html
Quoting:
This functionality is implemented in the remote stub; however, none of the stubs distributed with GDB support tracepoints as of this writing
I can't seem to get readable debugging output for programs compiled with GCC 4.7 MacPorts build.
I've tried with both GDB 6.3 and GDB 7.3 and each have their own problems.
Try with GDB 7.3 (MacPorts)
With GDB 7.3 I get the following output on startup:
$ ggdb ./test
GNU gdb (GDB) 7.3
Copyright (C) 2011 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-darwin11.4.0".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
BFD: unable to read unknown load command 0x24
BFD: unable to read unknown load command 0x26
BFD: unable to read unknown load command 0x24
BFD: unable to read unknown load command 0x26
Reading symbols from /Users/StackedCrooked/programming/projects/stacked-crooked/Playground/LockOrderChecker/test...Reading symbols from /Users/StackedCrooked/programming/projects/stacked-crooked/Playground/LockOrderChecker/test.dSYM/Contents/Resources/DWARF/test...done.
done.
Running and triggering an assertion results in an unreadable stack trace:
(gdb) r
Starting program: /Users/StackedCrooked/programming/projects/stacked-crooked/Playground/LockOrderChecker/test
BFD: unable to read unknown load command 0x24
BFD: unable to read unknown load command 0x26
main
Assertion failed: (false), function lock, file main.cpp, line 168.
Program received signal SIGABRT, Aborted.
0x00007fff8ede282a in ?? ()
(gdb) bt
#0 0x00007fff8ede282a in ?? ()
#1 0x00007fff9a273a9c in ?? ()
#2 0x00007fff6af00690 in ?? ()
#3 0x0000003000000030 in ?? ()
#4 0x00007fffffffffdf in ?? ()
#5 0x000000010b305840 in ?? ()
#6 0x00007fff6af006d0 in ?? ()
#7 0x00007fff9a2a65de in ?? ()
#8 0x0000000000000000 in ?? ()
Try with GDB 6.3 (built-in)
According to this answer I should use GDB 6.3. However that leads to a different set of problems. During startup I get a bunch of errors:
GNU gdb 6.3.50-20050815 (Apple version gdb-1708) (Thu Nov 3 21:59:02 UTC 2011)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries .
warning: Could not find object file "/Volumes/work/macports/var/macports/build/_Volumes_work_mports_dports_lang_gcc47/gcc47/work/build/x86_64-apple-darwin11/libstdc++-v3/src/.libs/compatibility.o" - no debug information available for "../../../../gcc-4.7.1/libstdc++-v3/src/c++98/compatibility.cc".
warning: Could not find object file "/Volumes/work/macports/var/macports/build/_Volumes_work_mports_dports_lang_gcc47/gcc47/work/build/x86_64-apple-darwin11/libstdc++-v3/src/.libs/compatibility-debug_list.o" - no debug information available for "../../../../gcc-4.7.1/libstdc++-v3/src/c++98/compatibility-debug_list.cc".
warning: Could not find object file "/Volumes/work/macports/var/macports/build/_Volumes_work_mports_dports_lang_gcc47/gcc47/work/build/x86_64-apple-darwin11/libstdc++-v3/src/.libs/compatibility-debug_list-2.o" - no debug information available for "../../../../gcc-4.7.1/libstdc++-v3/src/c++98/compatibility-debug_list-2.cc".
This is what I see if an assertion is triggered and I try to get a backtrace:
Assertion failed: (false), function lock, file main.cpp, line 168.
Program received signal SIGABRT, Aborted.
0x00007fff8ede282a in __kill ()
(gdb) bt
#0 0x00007fff8ede282a in __kill ()
#1 0x00007fff9a273a9c in abort ()
#2 0x00007fff9a2a65de in __assert_rtn ()
Die: DW_TAG_unspecified_type (abbrev = 19, offset = 423)
has children: FALSE
attributes:
DW_AT_name (DW_FORM_strp) string: "decltype(nullptr)"
Die: DW_TAG_unspecified_type (abbrev = 19, offset = 423)
has children: FALSE
attributes:
DW_AT_name (DW_FORM_strp) string: "decltype(nullptr)"
Dwarf Error: Cannot find type of die [in module /Users/StackedCrooked/programming/projects/stacked-crooked/Playground/LockOrderChecker/test.dSYM/Contents/Resources/DWARF/test]
According to this answer (which quotes the GCC 4.5 manual) I should use the -gdwarf-2 -gstrict-dwarf options.
I followed this advice. My build command looks like this:
g++ -o run-test -std=c++0x -Wall -Wextra -Werror -gdwarf-2 -gstrict-dwarf -g2 -O0 -I/opt/local/include main.cpp
However, it doesn't fix any of the aforementioned problems.
For the record: I'm on OS X Lion.
Does anyone know how to fix this?
According to the g++ man pages you should use -ggdb to generate debug symbols for gdb. BTW, just using -g always generated good symbols for gdb in my experience (on linux, windows (mingw) and mac).
The warnings from your MacPorts gdb 7.3 session are for load commands 0x24 (LC_VERSION_MIN_MACOSX) and 0x26 (LC_FUNCTION_STARTS). These are new load commands but are not essential for debugging - the warnings are harmless. The fact that your session lacks any symbolic information is maybe because of ASLR? It's been years since that was introduced into the system for user land debugging but that's what the debugger output can look like if it doesn't know that everything slid around in memory at runtime.
Have you tried using lldb? The version provided in Xcode 4.5 is really quite nice. It is the debugger that Apple is currently supporting and developing actively, and it should work with the DWARF output by more recent compilers correctly. The command syntax is a little different than gdb (although there are many command shortcuts provided that make it familiar to gdb users), there's a table of gdb/lldb command equivalences provided over at http://lldb.llvm.org/lldb-gdb.html. Give it a try, you might like it.
I am new to cgi and with an example I wrote a small program in c++ which I have compiled to a .cgi file.
My question is: do I need an separate web server? I have lighttpd as my default web server ... If i can run thought lighttpd please explain how can I do it...
Make sure your .cgi file is executable, and put it under your web root.
Turn on cgi http://redmine.lighttpd.net/wiki/1/Docs:ModCGI
go to the page. :)
Strictly speaking you don't need a server. If you just want to see your CGI running, you can use my tiny runCGI project.
All you need is to set a yaml file which looks something like this
_exec: /var/cgi-bin/myfile.cgi
method: GET
query_string:
q: s
and then run
./runCGI myyamlfile.yaml
You will see the output on the console's standard output.
You can even debug it with gdb, debug runCGI gdb runCGI, run with the correct parameters (run someyaml.yaml), issue tcatch exec (tcatch catches it only once) and then set breakpoints to your CGI file:
$ g++ a.cc -o a.out
$ cat a.yaml
method: GET
_exec: a.out
$ gdb runCGI
GNU gdb 6.8-debian
Copyright (C) 2008 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-linux-gnu"...
(gdb) tcatch exec
Catchpoint 1 (exec)
(gdb) run a.yaml
Starting program: /home/elazar/runCGI/runCGI a.yaml
Executing new program: /home/elazar/runCGI/a.out
0x00007fc3a24a6a60 in ?? () from /lib64/ld-linux-x86-64.so.2
(gdb) tbreak main
Breakpoint 2 at 0x400577: file a.cc, line 2.
(gdb) c
Continuing.
main (argc=1, argv=0x7fff14891408) at a.cc:2
2 int a =0;
(gdb)
How do I set up gdb on window so that it does not allow a program with assertion failure to terminate? I intend to check the stack trace and variables in the program.
For example, running this test.cpp program compiled with MinGW 'g++ -g test.cpp -o test' in gdb:
#include <cassert>
int main(int argc, char ** argv) { assert(1==2); return 0; }
Gives:
$ gdb test.exe
GNU gdb 6.8
Copyright (C) 2008 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 "i686-pc-mingw32"...
(gdb) r
Starting program: f:\code/test.exe
[New thread 4616.0x1200]
Error: dll starting at 0x77030000 not found.
Error: dll starting at 0x75f80000 not found.
Error: dll starting at 0x77030000 not found.
Error: dll starting at 0x76f30000 not found.
Assertion failed: 1==2, file test.cpp, line 2
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
Program exited with code 03.
(gdb)
I would like to be able to stop the program from terminating immediately, like how Visual Studio's debugger and gdb on Linux does it. I have done a search and found some stuff on trapping signals but I can't seem to find a good post on how to set up gdb to do this.
Found out that the breakpoint can be put in the .gdbinit file with the lines:
set breakpoint pending on
b exit
This removes the need to enter yes for windows.
Just set a breakpoint on exit:
(gdb) b exit
Using recent (March 2017) msys2 with gcc 6.3 and gdb 7.12.1 you should use:
break _exit
i.e. use _exit and not exit. I expect this also to work in other cases as I expect that exit will call _exit to actually exit.