#622 fixes for mingw64 - gcc4.5.1 tdm64-1

closed-fixed
5
2010-12-21
2010-09-05
mescalinum
No

mingw64 doesn't have SEH, and apparently amd64 arch (w64) doesn't need it.

Discussion

1 2 > >> (Page 1 of 2)
  • mescalinum
    mescalinum
    2010-09-05

     
  • mescalinum
    mescalinum
    2010-09-05

    tested against tcl8.5.8 and tcl8.5.9rc4

     
  • Don Porter
    Don Porter
    2010-09-07

    • priority: 5 --> 9
    • assigned_to: hobbs --> andreas_kupries
     
  • Don Porter
    Don Porter
    2010-09-07

    Andreas, is this configuration one of your test systems?

    Does this patch cause any trouble with your test systems?

     
  • Jan Nijtmans
    Jan Nijtmans
    2010-09-07

    This sounds to me that HAVE_NO_SEH is ill-determined
    in the configure script. It should not be necessary to
    test for _WIN64 separately.

     
  • @dgp While we have a 64bit windows box we are using the C compiler of the platform SDK, not gcc. The mingw we are using, is only to run bash, configure, etc., and it is a 32bit version too, just checked with depends.exe, cputype is x86, not amd64. So, no, this is not one of our configurations.

     
    • assigned_to: andreas_kupries --> dgp
     
  • Don Porter
    Don Porter
    2010-09-07

    • assigned_to: dgp --> andreas_kupries
     
  • Don Porter
    Don Porter
    2010-09-07

    nijtmans' comments sound right to me.
    Is it understood why HAVE_NO_SEH goes
    wrong on this platform?

     
  • I have no understanding of SEH at all, except that I know that the acronym expands to 'structured exception handling'. I also seem to remember that Kevin talked about it at some point in some way, the exact nature of which I have forgotten (It was over a year ago at least, more likely over two years). Another person which might know it is David Gravereaux IIRC. tclguy less so actually, I believe.

     
  • mescalinum
    mescalinum
    2010-09-07

    excuse me I didn't state explicitly what the patch was going (trying) to correct, which is a compile failure on mingw w64, because it has no SEH, and the assembler workaround is valid only for x86 (pushl, movl, are not amd64 instructions).
    I think the macro HAVE_NO_SEH it's set correct.
    maybe the check should be #if defined(__MINGW32__) && defined(_AMD64) && defined(HAVE_NO_SEH)

     
  • Jan Nijtmans
    Jan Nijtmans
    2010-09-07

    I knew I saw it before: This is a duplicate
    of [Patch #1910041], which contains a
    better solution. See my remarks there.

    I cannot test it, but I think we should
    be grateful to Kai Tietz and NightStrike
    for providing such a complete solution.

     
  • Jan Nijtmans
    Jan Nijtmans
    2010-09-07

    • status: open --> open-duplicate
     
  • Don Porter
    Don Porter
    2010-09-08

     
    Attachments
  • Don Porter
    Don Porter
    2010-09-08

    Here's my updated version of Patch 1910041.
    It needs testing on the mingw/amd64 system,
    which I do not have. mescalinum? Can you
    give it a test?

     
  • mescalinum
    mescalinum
    2010-09-08

    @dgp: compiler output:
    gcc -c -O2 -fomit-frame-pointer -Wall -I"./../generic" -DTCL_TOMMATH -DMP_PREC=4 -I"./../libtommath" -I"." -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DSTDC_HEADERS=1 -DHAVE_NO_SEH=1 -DHAVE_NO_LPFN_DECLS=1 -DHAVE_ALLOCA_GCC_INLINE=1 -DHAVE_CAST_TO_UNION=1 -DTCL_CFGVAL_ENCODING=\"cp1252\" -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DTCL_CFG_OPTIMIZED=1 -DTCL_CFG_DEBUG=1 -DBUILD_tcl "tclWin32Dll.c" -o tclWin32Dll.o
    tclWin32Dll.c: In function 'TclWinCPUID':
    tclWin32Dll.c:1125:28: warning: unused variable 'registration'
    \Temp\cc2FmRDa.s: Assembler messages:
    \Temp\cc2FmRDa.s:61: Error: Incorrect register `%rax' used with `l' suffix
    make: *** [tclWin32Dll.o] Error 1

     
  • Don Porter
    Don Porter
    2010-09-08

    Why are those lines being compiled?

     
  • Don Porter
    Don Porter
    2010-09-08

    I think I misread the message.

    If you change "movl" to "movq" on
    line 428, does it make things better?

     
  • Don Porter
    Don Porter
    2010-09-08

    kennykb comments at 1910041 suggest
    the approach of the patch here is the better
    way to go.

     
  • Don Porter
    Don Porter
    2010-09-08

     
    Attachments
  • Don Porter
    Don Porter
    2010-09-08

    I believe the new attached patch 3059922.patch
    gets all the logic errors corrected, without adding
    new assembly. Needs testing on all windows configurations.

     
  • mescalinum
    mescalinum
    2010-09-08

    @dgp:
    > If you change "movl" to "movq" on
    > line 428, does it make things better?

    yep, that made the trick.

    there's still a linker error at the end:
    Creating library file: libtcl85.atclWin32Dll.o:tclWin32Dll.c:(.text+0xc4): undefined reference to `_Tcl_Finalize'
    tclWinChan.o:tclWinChan.c:(.text+0xa69): undefined reference to `_CloseHandle
    '
    collect2: ld returned 1 exit status
    make: *** [tcl85.dll] Error 1

    these functions are referenced from assembler. maybe needs a different syntax.

     
  • mescalinum
    mescalinum
    2010-09-08

    @dgp: yes, 3059922.patch is ok. tested with tcl8.5.9rc4

     
  • Don Porter
    Don Porter
    2010-09-08

    committed to core-8-5-branch

     
  • Don Porter
    Don Porter
    2010-09-08

    ....and to HEAD

     
1 2 > >> (Page 1 of 2)