AVX-512 - Debugging application with Intel SDE not working

Viewed 412

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?

1 Answers

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