search

cucapra / dahlia

Time-sensitive affine types for predictable hardware generation
https://capra.cs.cornell.edu/dahlia
MIT License
128 stars 8 forks source link

Buildbot unable to find header files #153

Closed sa2257 closed 5 years ago

sa2257 commented 5 years ago

This is to track diagnostics run to find why Buildbot complains about not finding header files from #32.

1- Do MachSuite apps really need headers? 2- Do these work locally? 3- Does it work outside the container? 4- Does manual runs inside the container fail? 5- More detailed logs from gcc -v

sa2257 commented 5 years ago

1- MachSuite fft transpose fails without math.h job

WARNING: [HLS 200-40] In file included from /seashell/buildbot/instance/jobs/Seulxz-MAw8/code/fft.cpp:6:
/seashell/buildbot/instance/jobs/Seulxz-MAw8/code/fft.h:11:10: fatal error: 'math.h' file not found
#include <math.h>
         ^
ERROR: [HLS 200-70] Compilation errors found:
Pragma processor failed: In file included from /seashell/buildbot/instance/jobs/Seulxz-MAw8/code/fft.cpp:6:
/seashell/buildbot/instance/jobs/Seulxz-MAw8/code/fft.h:11:10: fatal error: 'math.h' file not found
#include <math.h>

2- They seem to work locally check log.txt in job which is a local run which gives results

  Estimated hardware latency = 950698
  Estimated resource usage:
    dsps used = 281/220
    bram used = 15/140
    luts used = 45878/53200
    FFs used = 46443/106400

Also it runs for stdlib and stdio

rachitnigam commented 5 years ago

This answer on the Xilinx forum might help: https://www.xilinx.com/support/answers/52971.html

Also, this: https://forums.xilinx.com/t5/Embedded-Processor-System-Design/error-while-using-math-h-library-in-zynq-7000-zc-702-board/td-p/785000

Note that the -m option was removed from buildbot in #144

rachitnigam commented 5 years ago

Also, this tutorial video implies that the correct way to using math.h is using the HLS_MATH.h library. They note you don't have to use them, but using hls_math makes sure that the simulation results are consistent w.r.t to the synthesized results.

sa2257 commented 5 years ago
  1. Run from workproc gives same header file error

Oddly, it runs without -sds-hw specification i.e. sds++ -sds-pf zed -c fft.cpp -o fft.o which just compiles in sw.

something odd I ran into Extra space breaks the command

sds++ -sds-pf zed  -sds-hw fft ./fft.cpp -sds-end -c fft.cpp -o fft.o

two spaces after zed

WARNING: [SdsCompiler 83-5110] Software platform XML file was not found, unable to resolve platform configuration
ERROR: [SdsCompiler 83-5106] Platform specified as zed  but the hw platform XML file was not found - is the platform name correct and is the path to the platform correct (if required)?
ERROR: [SdsCompiler 83-5004] Build failed
sampsyo commented 5 years ago

Seriously?? -sds-pf zed␣␣ is different from -sds-pf zed␣????? Come on, Xilinx! :rage:

sa2257 commented 5 years ago

I don't think that happens locally. I basically copied the local command and ran on container. It just came up in the container.

sampsyo commented 5 years ago

That makes me feel a little better!

rachitnigam commented 5 years ago

@sa2257 Does using the -m flag help?

sa2257 commented 5 years ago

Command run with -v

outside container works

inside container fails

inside container without specifying as hw works

I didn't get anything useful from the reports though.

sa2257 commented 5 years ago

And no, -Ms didn't help. I also removed all optimization flags etc.

sampsyo commented 5 years ago

In those two runs, I note that the include paths are quite different. In the outside-container log, it says:

#include <...> search starts here:
 /opt/Xilinx/SDx/2017.2/target/aarch32-linux/include
 /home/sa2257/workspace/lachea/epoisses/mach-fft_transpose
 /opt/Xilinx/SDx/2017.2/Vivado_HLS/include
 /opt/Xilinx/SDx/2017.2/SDK/gnu/aarch32/lin/gcc-arm-linux-gnueabi/arm-linux-gnueabihf/include/c++/6.2.1
 /opt/Xilinx/SDx/2017.2/SDK/gnu/aarch32/lin/gcc-arm-linux-gnueabi/arm-linux-gnueabihf/include/c++/6.2.1/arm-linux-gnueabihf
 /opt/Xilinx/SDx/2017.2/SDK/gnu/aarch32/lin/gcc-arm-linux-gnueabi/arm-linux-gnueabihf/include/c++/6.2.1/backward
 /opt/Xilinx/SDx/2017.2/SDK/gnu/aarch32/lin/gcc-arm-linux-gnueabi/lib/gcc/arm-linux-gnueabihf/6.2.1/include
 /opt/Xilinx/SDx/2017.2/SDK/gnu/aarch32/lin/gcc-arm-linux-gnueabi/lib/gcc/arm-linux-gnueabihf/6.2.1/include-fixed
 /opt/Xilinx/SDx/2017.2/SDK/gnu/aarch32/lin/gcc-arm-linux-gnueabi/arm-linux-gnueabihf/include
 /opt/Xilinx/SDx/2017.2/SDK/gnu/aarch32/lin/gcc-arm-linux-gnueabi/arm-linux-gnueabihf/libc/usr/include
 /usr/local/include
 /usr/include
End of search list.

In the inside-container log, it says:

#include <...> search starts here:
 /opt/Xilinx/SDx/2017.2/target/aarch32-linux/include
 /seashell/buildbot/instance/jobs/sFYBFAyU33U/code
 /opt/Xilinx/SDx/2017.2/Vivado_HLS/lnx64/tools/systemc/include
 /opt/Xilinx/SDx/2017.2/Vivado_HLS/include
 /opt/Xilinx/SDx/2017.2/Vivado_HLS/include/ap_sysc
 /opt/Xilinx/SDx/2017.2/Vivado_HLS/common/technology/autopilot
 /opt/Xilinx/SDx/2017.2/Vivado_HLS/lnx64/tools/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.6.3/../../../../include/c++/4.6.3
 /opt/Xilinx/SDx/2017.2/Vivado_HLS/lnx64/tools/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.6.3/../../../../include/c++/4.6.3/x86_64-unknown-linux-gnu/32
 /opt/Xilinx/SDx/2017.2/Vivado_HLS/lnx64/tools/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.6.3/../../../../include/c++/4.6.3/backward
 /usr/local/include
 /opt/Xilinx/SDx/2017.2/Vivado_HLS/lnx64/tools/clang/bin/../lib/clang/3.1/include
 /usr/include
End of search list.

That could explain it, if something like math.h is in one of the directories in the first list but not in the second. A little more staring at the logs might help reveal why the include paths are being set up that way.

sampsyo commented 5 years ago

To answer my own question, math.h is indeed in this directory, which is in the first list but not the second:

/opt/Xilinx/SDx/2017.2/SDK/gnu/aarch32/lin/gcc-arm-linux-gnueabi/arm-linux-gnueabihf/libc/usr/include

You can reproduce this problem using this code in a file called foo.cpp:

#include <math.h>

float foo(float x) {
    return cos(x + 1.0);
}

And typing this command inside (or outside) our xilinx container:

$ sds++ -sds-pf zed -sds-hw foo foo.cpp -sds-end -verbose -c foo.cpp
sa2257 commented 5 years ago

FWIW, I get different logs with verbose and -v. -verbose which is a Xilinx flag doesn't seem to give me include search list, where as -v does.

logs for above test in this job

sampsyo commented 5 years ago

Using -v and -verbose, I tracked the first error to this invocation:

$ "/opt/Xilinx/SDx/2017.2/Vivado_HLS/lnx64/tools/clang/bin/clang" -cc1 -triple i386-unknown-linux-gnu -emit-llvm-bc -disable-free -disable-llvm-verifier -main-file-name foo.cpp -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -hls -target-cpu pentium4 -target-linker-version 2.26.20160125 -momit-leaf-frame-pointer -v -coverage-file /root/_sds/vhls/foo/solution/.autopilot/db/foo.pp.00.o -resource-dir /opt/Xilinx/SDx/2017.2/Vivado_HLS/lnx64/tools/clang/bin/../lib/clang/3.1 -include etc/autopilot_ssdm_op.h -D __SDSCC__ -D __SDSVHLS__ -D __SDSVHLS_SYNTHESIS__ -D __CLANG_3_1__ -I /opt/Xilinx/SDx/2017.2/target/aarch32-linux/include -I /root -I /root -I /opt/Xilinx/SDx/2017.2/Vivado_HLS/lnx64/tools/systemc/include -I /opt/Xilinx/SDx/2017.2/Vivado_HLS/include -I /opt/Xilinx/SDx/2017.2/Vivado_HLS/include/ap_sysc -I /opt/Xilinx/SDx/2017.2/Vivado_HLS/common/technology/autopilot -fmodule-cache-path /var/tmp/clang-module-cache -internal-isystem /opt/Xilinx/SDx/2017.2/Vivado_HLS/lnx64/tools/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.6.3/../../../../include/c++/4.6.3 -internal-isystem /opt/Xilinx/SDx/2017.2/Vivado_HLS/lnx64/tools/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.6.3/../../../../include/c++/4.6.3/x86_64-unknown-linux-gnu/32 -internal-isystem /opt/Xilinx/SDx/2017.2/Vivado_HLS/lnx64/tools/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.6.3/../../../../include/c++/4.6.3/backward -internal-isystem /usr/local/include -internal-isystem /opt/Xilinx/SDx/2017.2/Vivado_HLS/lnx64/tools/clang/bin/../lib/clang/3.1/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -O0 -w -fdeprecated-macro -fdebug-compilation-dir /root/_sds/vhls -ferror-limit 19 -fmessage-length 0 -fno-limit-debug-info -mstackrealign -fno-threadsafe-statics -fno-use-cxa-atexit -fgnu-runtime -fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-fragile-abi -fcxx-exceptions -fexceptions -fdiagnostics-show-option -disable-llvm-optzns -o /tmp/foo.out -x c++ foo.cpp
clang -cc1 version 3.1 based upon LLVM 3.1 default target x86_64-unknown-linux-gnu
ignoring nonexistent directory "/include"
ignoring duplicate directory "/root"
#include "..." search starts here:
#include <...> search starts here:
 /opt/Xilinx/SDx/2017.2/target/aarch32-linux/include
 /root
 /opt/Xilinx/SDx/2017.2/Vivado_HLS/lnx64/tools/systemc/include
 /opt/Xilinx/SDx/2017.2/Vivado_HLS/include
 /opt/Xilinx/SDx/2017.2/Vivado_HLS/include/ap_sysc
 /opt/Xilinx/SDx/2017.2/Vivado_HLS/common/technology/autopilot
 /opt/Xilinx/SDx/2017.2/Vivado_HLS/lnx64/tools/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.6.3/../../../../include/c++/4.6.3
 /opt/Xilinx/SDx/2017.2/Vivado_HLS/lnx64/tools/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.6.3/../../../../include/c++/4.6.3/x86_64-unknown-linux-gnu/32
 /opt/Xilinx/SDx/2017.2/Vivado_HLS/lnx64/tools/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.6.3/../../../../include/c++/4.6.3/backward
 /usr/local/include
 /opt/Xilinx/SDx/2017.2/Vivado_HLS/lnx64/tools/clang/bin/../lib/clang/3.1/include
 /usr/include
End of search list.
foo.cpp:1:10: fatal error: 'math.h' file not found
#include <math.h>
         ^
1 error generated.

(That's reproducible, i.e., you can copy n' paste that command into the container or the host with my above foo.cpp to observe the error disappearing.)

Here, the include lists are identical. It turns out that, on the host, /usr/include/math.h exists but, in the container, it does not. So the compiler is finding the system's header file (not one that shipped with Vivado at al!!!), but that's only possible on the host.

There are two possibilities here:

sampsyo commented 5 years ago

I installed the package glibc-devel.i686 in the container, and all the appropriate headers appeared, and the sds++ command now works. So I think our Docker container for the Xilinx tools just needs something like this added:

RUN yum install glibc-devel.i686
sa2257 commented 5 years ago

That's quite interesting. Ideally, it seems we should use Vivado provided math header. But unfortunately MachSuite uses standard header, and even SDx examples use other standard headers.

Also, it's annoying that the tool uses a different header file in "moving function to programmable logic" phase.