riscvarchive / riscv-binutils-gdb

RISC-V backports for binutils-gdb. Development is done upstream at the FSF.
GNU General Public License v2.0
148 stars 233 forks source link

Linux build succeeds but Windows (cross) tools build fails #124

Closed TommyMurphyTM1234 closed 6 years ago

TommyMurphyTM1234 commented 6 years ago

Overnight I tried to build the latest stuff from the repo and while the linux build completed the windows one failed:

x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -DWITH_DEFAULT_MODEL='"RV64G"' -DWITH_ALIGNMENT=NONSTRICT_ALIGNMENT -DWITH_TARGET_WORD_BITSIZE=64 -DWITH_TARGET_BYTE_ORDER=BFD_ENDIAN_LITTLE   -DDEFAULT_INLINE=0   -w      -I. -I/Host/Work/riscv64-unknown-elf/riscv-binutils-gdb.git/sim/riscv -I../common -I/Host/Work/riscv64-unknown-elf/riscv-binutils-gdb.git/sim/riscv/../common -I../../include -I/Host/Work/riscv64-unknown-elf/riscv-binutils-gdb.git/sim/riscv/../../include -I../../bfd -I/Host/Work/riscv64-unknown-elf/riscv-binutils-gdb.git/sim/riscv/../../bfd -I../../opcodes -I/Host/Work/riscv64-unknown-elf/riscv-binutils-gdb.git/sim/riscv/../../opcodes  -Wno-unknown-warning-option -Wno-extended-offsetof -Wno-deprecated-declarations -Wno-incompatible-pointer-types-discards-qualifiers -Wno-implicit-function-declaration -Wno-parentheses -Wno-format-nonliteral -Wno-shift-count-overflow -Wno-constant-logical-operand -Wno-shift-negative-value -Wno-format -pipe -ffunction-sections -fdata-sections -D__USE_MINGW_ACCESS -static-libstdc++ -static-libgcc -L/tmp/install/win64/lib -Wl,--gc-sections -Wl,--stack,12582912 -o run.exe \
  nrun.o libsim.a ../../bfd/libbfd.a ../../opcodes/libopcodes.a  ../../libiberty/libiberty.a -L../../zlib -lz  
libsim.a(sim-main.o):sim-main.c:(.text$execute_i+0x365b9): undefined reference to `link'
collect2: error: ld returned 1 exit status
make[3]: *** [run.exe] Error 1
Makefile:272: recipe for target 'run.exe' failed
make[3]: Leaving directory '/tmp/build/win64/binutils-gdb/sim/riscv'
make[2]: *** [all] Error 1
Makefile:129: recipe for target 'all' failed
make[2]: Leaving directory '/tmp/build/win64/binutils-gdb/sim'
make[1]: *** [all-sim] Error 2
Makefile:9539: recipe for target 'all-sim' failed
make[1]: Leaving directory '/tmp/build/win64/binutils-gdb'
make: *** [all] Error 2
Makefile:856: recipe for target 'all' failed

It seems odd that linux completed but windows failed but, on Friday, I had the same experience with this issue where the linux build completed and the windows one did not:

https://github.com/riscv/riscv-openocd/issues/150

Anyway for the RISC-V gcc tools I am using a slightly modified version of Liviu's GNU MCU Eclipse build process and scripts which includes cross compilation from a linux docker image for Windows:

https://github.com/gnu-mcu-eclipse/riscv-none-gcc-build

And I am telling it to build the following:

export BINUTILS_GIT_URL=https://github.com/riscv/riscv-binutils-gdb.git
export BINUTILS_GIT_BRANCH=riscv-binutils-2.29
export BINUTILS_GIT_COMMIT=9b4d67248adb045caa8f166c59a0081867cc6cb2

Any ideas? Thanks.

ilg-ul commented 6 years ago

the problem seems different from https://github.com/riscv/riscv-openocd/issues/150

at first sight it looks like a missing library.

it would be easier if we could compare to an official build, preferable that runs on Travis to validate each commit.

is there such a Travis script, in some other repo? (since here I could not find one).

TommyMurphyTM1234 commented 6 years ago

the problem seem different from riscv/riscv-openocd#150

Yes - I didn't mean to imply that the two issues were the same but was just pointing out another case where, strangely in that case, the linux build worked but the windows one did not.

is there such a Travis script, in some other repo? (since here I could not find one).

Isn't that what this discussion was about?

https://groups.google.com/a/groups.riscv.org/forum/#!topic/sw-dev/HdkwlJF4JXA

jim-wilson commented 6 years ago

link is a POSIX syscall. mingw of course does not support it.

Kito added some syscall emulation code to the RISC-V simulator so that it could successfully run more programs. One of these new syscalls is for link. There are a few things we can do here. We can ifdef out the link support when built on mingw. We can add a routine to libiberty that emulates the POSIX link function for windows. We can remove the syscall support from the simulator, and declare that the BSP (i.e. libgloss) must provide this functionality. Or we could just drop support for link and let programs that call it fail.

The easy one is to ifdef out the code that calls link on Windows.

diff --git a/sim/riscv/sim-main.c b/sim/riscv/sim-main.c
index 5200c86445..444e4b829f 100644
--- a/sim/riscv/sim-main.c
+++ b/sim/riscv/sim-main.c
@@ -1764,6 +1764,7 @@ execute_i (SIM_CPU *cpu, unsigned_word iw, const struct riscv_opcode *op)

          switch (cpu->a7)
            {
+#ifndef __MINGW32__
            case TARGET_SYS_link:
              {
                char oldpath[1024], newpath[1024];
@@ -1772,6 +1773,7 @@ execute_i (SIM_CPU *cpu, unsigned_word iw, const struct riscv_opcode *op)
                cpu->a0 = link (oldpath, newpath);
                break;
              }
+#endif
            case TARGET_SYS_brk:
              {
                /* FIXME: Check the invalid access.  */
TommyMurphyTM1234 commented 6 years ago

Thanks a lot Jim - I'll make that mod locally and try a new build. Presumably one of the options that you outline should be chosen and applied [to the mater repo] to ensure that things build on windows/mingw (cross build from linux in my case) again?

Edit: update - yes that allowed the windows build to complete successfully. Thanks again.

jim-wilson commented 6 years ago

Patch committed.