On 09/10/2019 12:22, Luc Van Oostenryck wrote: > On Wed, Oct 09, 2019 at 02:03:19AM +0100, Ramsay Jones wrote: >> >> >> On 08/10/2019 22:57, Ramsay Jones wrote: >>> >>> >>> On 07/10/2019 10:06, Luc Van Oostenryck wrote: >>>> The source code can be found at its usual repository: >>>> git://git.kernel.org/pub/scm/devel/sparse/sparse.git v0.6.1-rc2 >>>> >>>> The tarballs are found at: >>>> https://www.kernel.org/pub/software/devel/sparse/dist/ >>>> >>> >>> Luc, I tested (last night) in the usual way on 64-&32-bit Linux >>> and 64-bit cygwin, without issue. I had intended to test (tonight) >>> also on fedora 30 and Ubuntu 19.04 (19.10 is still in beta), since >>> my normal test targets are all built on a fairly old base. However, >>> I didn't find time tonight, sorry ... :( >> >> OK, I lied. I managed to do a quick test on fedora 30 tonight >> after all! No issues found. :-D > > Awww, thanks a lot for this. No problem. > For my part, I've tested on the most recent unstable/dev version of > Debian & Ubuntu and everything was fine.> > Before the release, I would like to add the patch for the problem > you had with Cygwin. Would you be fine with the: > LLC_ARCH_OPTS="$LLC_ARCH_OPTS -mtriple=$(llvm-config --host-target)" > we had discussed before, with a note saying it's needed for recent > cygwin64 but may be inadequate for cygwin32? Ha, yes, I should have mentioned that, on cygwin, I actually tested: $ sparse --version v0.6.1-rc2-dirty $ ... where the 'dirty' was: $ git diff diff --git a/sparsec b/sparsec index bafe2da..8a056e7 100755 --- a/sparsec +++ b/sparsec @@ -39,6 +39,7 @@ case "$(uname -s)" in *CYGWIN*) # cygwin uses the sjlj (setjmp-longjmp) exception model LLC_ARCH_OPTS="-exception-model=sjlj" + LLC_ARCH_OPTS="$LLC_ARCH_OPTS -mtriple=x86_64-unknown-windows-cygnus" ;; *) ;; $ Given that: $ llvm-config --host-target x86_64-unknown-windows-cygnus $ ... the above should be just fine. (Do you want me to send a tested patch?). Note that I have been messing around with 'sparsec' and, in particular the invocation of llc, which can also output the object file directly. ie there is no need to generate assembler output and then assemble with the platform assembler. (which allows us to sidestep the incorrect assembler directives used for the wineh exception model!). However, 'sparsec' seems to have several problems (not just on cygwin). For example, on Linux, we see: $ ./sparsec -o hello hello.c /usr/bin/ld: /tmp/tmp.F57wOC: relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIC /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: error: ld returned 1 exit status $ whereas, on cygwin: $ ./sparsec -o hello hello.c $ ./hello.exe hello world $ ... which was somewhat surprising! ;-) Note that the testsuite is happy if 'sparcec' produces an object file without error - it never tests the creation of an executable (let alone that it actually runs and produces correct output). So, I don't know if we want to bust a gut to fix this up. ATB, Ramsay Jones
