riscv-software-src / riscv-tools

RISC-V Tools (ISA Simulator and Tests)
1.13k stars 446 forks source link

ld_new.exe blocked by Bitdefender (MINGW64) for 64 bit arch #315

Open MichaelsChild opened 3 years ago

MichaelsChild commented 3 years ago

Hi,

When compiling the toolchain under MINGW64, ld_new.exe is executed along the way. It fails since it is blocked by Bitdefender because it is identified as a threat - Gen:Variant.Ulise.110376.

Any idea what this might be?

Thanks.

jim-wilson commented 3 years ago

It is most likely a bug in bitdefender. It is a common problem for Windows anti-virus software to fail on cygwin/mingw32 programs because they only test against windows programs, they don't test their products against cygwin/mingw32. Report it as a false positive to bitdefender, Or maybe temporarily switch it off or temporarily switch to a different anti-virus provider.

MichaelsChild commented 3 years ago

Thanks! I switched if off since I thought that BD might be the reason why some folders are also not populated. I was following these instructions, https://mindchasers.com/dev/rv-getting-started, to build the toolchain and after successful build in MINGW64 for both 32 and 64 bit architecture I inspected the tree (as suggested). My include folder, for both 32 and 64 arch, was empty and other folders were not populated as suggested. I must have missed a step I guess but my build did not report any errors this time (except for 32 bit build in terminal.c about multiple definitions of *PC which I resolved somehow).

Maybe you would have and idea what I've been missing.

Thank you for you responses, they mean a lot.

jim-wilson commented 3 years ago

Probably your build was not successful, and you missed the error message. If you type "make" again, and stuff happens, then the build is not complete. It should give the error message again. If you can redirect make output to a file, then search the file for the string "error:" you should be able to find the problem so that you can report it.

There is a known problem with using gcc-10 on mingw to build gdb. Somewhere there is a missing extern, though I don't know if it is gdb or one of the mingw libraries that is missing the extern. gcc-10 makes -fno-common the default, whereas gcc-9 makes -fcommon the default, so programs with missing externs may compile with gcc-9 but fail to compile with gcc-10.

aswaterman commented 3 years ago

I’ve fixed the bug in riscv-tests that was inadvertently relying on -fcommon. I’ll try to update that within riscv-tools soon.

MichaelsChild commented 3 years ago

Hi I have followed your advice and I am able to provide you make log (attached). I was not able to find a report that might indicate there was an error in build or copying. build64.zip

After executing this build my tree looks like this (attached)

treeinfo.txt

I am missing gdb and some other files. Is there any additional action that I need to take to complete the toolchain.

Thank you!

MichaelsChild commented 3 years ago

Just to mention I still used gcc v10

jim-wilson commented 3 years ago

gdb failed to build. There is an error due to the -fno-common change in gcc v10.

C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w\ 64-mingw32/bin/ld.exe: C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1\ .0/../../../../lib/libncursesw.a(lib_termcap.o):(.bss+0x8): multiple definition\ of `UP'; ../readline/libreadline.a(terminal.o):terminal.c:(.bss+0x90): first d\ ,efined here^M

I think this is actually a bug in the termcap library, but you can work around it by adding an extern to gdb. In the file readline/readline/terminal.c there is a line char PC, BC, UP; and change it to extern char PC, BC, UP; or else arrange for NEED_EXTERN_PC to be defined.

There is also a second error

C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w\ 64-mingw32/bin/ld.exe: ada-tasks.o:C:/msys64/mingw64/x86_64-w64-mingw32/include\ /string.h:202: undefined reference to `__memcpy_chk'^M

I don't know offhand why you are getting this error. That function should be in the mingw C library. This bug report https://github.com/msys2/MINGW-packages/issues/5868 suggests a recent change to cygwin requires changes to mingw Makefiles to add the -lssp library when linking. Maybe our gdb doesn't have that change yet. You could try hacking the makefile to add -lssp to the link command.

It is much easier to build a windows toolchain cross hosted on linux. We don't do windows native builds very often. SiFive has toolchain binaries on its web site, include the SiFive toolchain and various third party toolchains. If you don't need to modify the sources, you could just download one instead of building on.