- Glasgow-haskell-users

vectors
by John Meacham 26 Oct '05

26 Oct '05

as an interesting tidbit, gcc now supports using vector (SIMD) types directly as if they were normal C types in a portable way.. I wonder how hard it would be to expose these types to the user in ghc? http://gcc.gnu.org/onlinedocs/gcc-4.0.2/gcc/Vector-Extensions.html things like matricies and complex numbers might be greatly sped up. John -- John Meacham - ⑆repetae.net⑆john⑈

1 0

RE: GHC and Windows (DLL/FFI) woes
by Simon Marlow 26 Oct '05

26 Oct '05

On 23 October 2005 19:00, Esa Ilari Vuokko wrote: > I have been trying to build some Windows DLLs with > GHC, and I have run into some misfeatures or maybe > I have misunderstood how to use GHC. Any help or > advice would be appreciated. :) > > First of all, I can't get ghc to generate stubs from > foreign export in anywhere else than next to original > source, which is sort of annoying. I would like all > the generated files to go quite a bit diffrent place than > source directory. We don't have a flag for that; perhaps we should. Or perhaps there should be a flag that says "put all generated files here", that subsumes -odir, -hidir, -hcdir and also coveres _stub.{c,h} files. > Next, --make and --mk-dll don't seem to work together. > Ok, what I do, is I just --make -no-link and then --mk-dll > all the object files I find :) That's true. This is closer to working in 6.5, we should make it work (if anyone's interested, this just means hooking up DriverPipeline.link with DriverPipeline.doMkDLL in the right way). > It seems that -i flag and compiling those _stub.c have > following problem: if path given in -i flag contains any > /- or \-characters, i.e. any real subpaths, it seems to > stop with something like: > \source\sunrise\haskell\haskell\..\debug\build\haskell\plugin-hs-test/d: : > createDirectory: invalid argument (Invalid argument) > It seems a bit random what is the supposed "filename" > part of the path, typically it contains drive letter and few > colons, it doesn't seem totally random data. Could you give me a detailed description of the problem: the exact command line, and the error message that is produced. Thanks. Cheers, Simon

2 1

RE: GHC-6.4.1 on FreeBSD-amd64 port progress
by Simon Marlow 25 Oct '05

25 Oct '05

On 24 October 2005 19:04, Wilhelm B. Kloke wrote: > Wilhelm B. Kloke <wb(a)arb-phys.uni-dortmund.de> schrieb: >> Simon Marlow <simonmar(a)microsoft.com> schrieb: >>> >>> Are you building GHC in a fresh tree now? I'd recommend doing that. >> >> Now I am using a *really* fresh tree. Formerly the compilation of >> Apply.cmm did not render an instructive error message, just >> failed for some sort of memory access exception. Now I have: >> > I have enabled freebsd in the mangler now. After installing with > make install stage=1 > the compiler compiles an .o and .hi file, but it does not find the > libraries to link with for test.hs. Is it that it does not find the libraries, or does it find the libraries but still gets a bunch of undefined references? If the latter, then there could be an issue with the mangler. Try an 'nm' on libHSbase.a to see if the missing symbols are actually defined. Cheers, Simon

2 1

Re: Default name of target executable
by Tomasz Zielonka 24 Oct '05

24 Oct '05

On 10/14/05, Tomasz Zielonka <tomasz.zielonka(a)gmail.com> wrote: > On 10/14/05, Simon Peyton-Jones <simonpj(a)microsoft.com> wrote: > > HEAD definitely. We don't change the specification of STABLE, only fix > > bugs. > > Great, I have the initial implementation, but I'll try to make it > prettier. Here is the patch. Some notes: - I am not sure if it's OK to modify Session in this place. Perhaps my code should be called from DriverPipeline.staticLink, but it has no access to module graph, and I didn't want to make such a big change - I wanted to add .exe suffix on Windows, but if I think that GHC relies on mingw32 tools to add it when necessary. - There is some documentatin in separate_compilation.xml. I wrote about the ability to put Main in file other than Main.hs, but I couldn't find documentation for this feature. Tell me if there are other places where this feature should be mentioned. - I didn't check that docs are properly generated after my changes. Besides, the language can be incorrect. Best regards Tomasz

1 1

RE: GHC-6.4.1 on FreeBSD-amd64 port progress
by Simon Marlow 24 Oct '05

24 Oct '05

On 18 October 2005 20:26, Wilhelm B. Kloke wrote: > Simon Marlow <simonmar(a)microsoft.com> schrieb: >> >> At this point you can either do 'make install stage=1', or you can >> just use the compiler you built to build a clean GHC in another >> tree, i.e. with ./configure >> --with-ghc=/path/to/bootstrap/ghc/compiler/ghc-inplace. > > Now I am getting the following really strange error message: > > ==fptools== gmake all -wr; > in /data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/ghc/compiler > ------------------------------------------------------------------------ > /data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/ghc/compiler/ghc-inplace > -H16m -O -istage1/utils -istage1/basicTypes -istage1/types > -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck > -istage1/deSugar -istage1/coreSyn -istage1/specialise > -istage1/simplCore -istage1/stranal -istage1/stgSyn > -istage1/simplStg -istage1/codeGen -istage1/main > -istage1/profiling -istage1/parser -istage1/cprAnalysis > -istage1/compMan -istage1/ndpFlatten -istage1/iface -istage1/cmm > -istage1/nativeGen -istage1/ghci -Istage1 -DGHCI -package > template-haskell -package readline -DUSE_READLINE -cpp -fglasgow-exts > -fno-generics -Rghc-timing -I. -IcodeGen -InativeGen -Iparser > -package unix -ignore-package lang -recomp -Rghc-timing -H16M > '-#include "hschooks.h"' -i../lib/compat -ignore-package Cabal -H80m > -c prelude/PrimOp.lhs -o stage1/prelude/PrimOp.o -ohi > stage1/prelude/PrimOp.hi > > prelude/PrimOp.lhs:104:0: parse error (possibly incorrect indentation) > <<ghc: 30809992 bytes, 2 GCs, 129776/129776 avg/max bytes residency > (1 samples), 60M in use, 0.00 INIT (0.00 elapsed), 0.08 MUT (0.10 > elapsed), 0.01 GC (0.02 elapsed) :ghc>> > gmake[2]: *** [stage1/prelude/PrimOp.o] Fehler 1 > gmake[1]: *** [install] Fehler 1 > gmake[1]: Leaving directory > `/data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/ghc' > gmake: *** [install] Fehler 1 > > I checked that PrimOp.lhs is identical with the versions in > -i386amd64 and -amd64, so the error message text is certainly > misleading. PrimOp.lhs includes a bunch of files that are auto-generated from primops.txt. In ghc/compiler you should have a bunch of files called primop-*-incl, which are generated by the genprimopcode program in ghc/utils/genprimopcode. If these files are empty or corrupt, just remove them and re-build. Are you building GHC in a fresh tree now? I'd recommend doing that. Cheers, Simon

2 2

RE: Segfaulting programs with GHC 6.4.1
by Simon Marlow 24 Oct '05

24 Oct '05

On 22 October 2005 03:25, John Goerzen wrote: > Here's some more data. > > I tried this program with three versions of GHC. > > GHC 6.4 with forkIO: could not produce a segfault at all > GHC 6.4 with forkOS: rapid segfault (<30 sec) > > GHC 6.4.1 with forkIO: segfault in <5 min > GHC 6.4.1 with forkOS: segfault in <1 min > > GHC 6.5: same results as GHC 6.4.1 > > Now, I also obtained a backtrace from GHC 6.4 with forkOS. Here's a > bit of it: > > #0 0x080c2e3e in ForeignziCziString_zdwpeekCAString_info () > #1 0xb7a9e868 in ?? () > #2 0x00000020 in ?? () > #3 0xb7ecb08c in _res () from /lib/tls/libc.so.6 > #4 0xb7ad80ec in ?? () > #5 0x00000004 in ?? () > #6 0x016b0d36 in ?? () > #7 0xb7ac3f9c in ?? () > #8 0x93c0cef9 in ?? () > #9 0x4359a1e1 in ?? () > #10 0x000742d3 in ?? () > #11 0x00000000 in ?? () > .... > #2021 0x00000000 in ?? () > #2022 0xb7ed80a6 in __pthread_mutex_cond_lock () from > /lib/tls/libpthread.so.0 #2023 0x080c2f4c in > ForeignziCziString_zdwpeekCAString_info () > > now this is the first time something from pthread actually appeared, > which is interesting. > > The code surrounding that CAString_info is: > > 0x080c2f44 <ForeignziCziString_zdwpeekCAString_info+356>: and > %eax,(%eax) 0x080c2f46 <ForeignziCziString_zdwpeekCAString_info+358>: > add %al,(%eax) 0x080c2f48 > <ForeignziCziString_zdwpeekCAString_info+360>: and $0x0,%al > 0x080c2f4a <ForeignziCziString_zdwpeekCAString_info+362>: add > %al,(%eax) 0x080c2f4c <ForeignziCziString_zdwpeekCAString_info+364>: > movl $0x80c2f10,0x0(%ebp) 0x080c2f53 > <ForeignziCziString_zdwpeekCAString_info+371>: jmp *(%esi) > 0x080c2f55 <ForeignziCziString_zdwpeekCAString_info+373>: nop > 0x080c2f56 <ForeignziCziString_zdwpeekCAString_info+374>: nop Hi John, Thanks for trying to narrow this down. At this stage it looks like some kind of heap corruption. Can you reproduce it on more than one machine? (we have to rule out hardware failure, it's happened before and can cost a lot of debugging time). BTW, the stack trace isn't useful beyond the top element, the reason being that GHC's virtual machine doesn't use the C stack. gdb can usually tell you which bit of code the crash happened in, but if it was in Haskell code then you don't have any information from the C stack. I'll need to reproduce it here. Can you give me a set of instructions to get me up to the right point? Cheers, Simon

2 1

GHC and Windows (DLL/FFI) woes
by Esa Ilari Vuokko 23 Oct '05

23 Oct '05

Hi! I have been trying to build some Windows DLLs with GHC, and I have run into some misfeatures or maybe I have misunderstood how to use GHC. Any help or advice would be appreciated. :) First of all, I can't get ghc to generate stubs from foreign export in anywhere else than next to original source, which is sort of annoying. I would like all the generated files to go quite a bit diffrent place than source directory. Next, --make and --mk-dll don't seem to work together. Ok, what I do, is I just --make -no-link and then --mk-dll all the object files I find :) It seems that -i flag and compiling those _stub.c have following problem: if path given in -i flag contains any /- or \-characters, i.e. any real subpaths, it seems to stop with something like: \source\sunrise\haskell\haskell\..\debug\build\haskell\plugin-hs-test/d:: createDirectory: invalid argument (Invalid argument) It seems a bit random what is the supposed "filename" part of the path, typically it contains drive letter and few colons, it doesn't seem totally random data. Thanks, --Esa Ilari Vuokko

1 0

RE: Segfaulting programs with GHC 6.4.1
by Simon Marlow 22 Oct '05

22 Oct '05

On 21 October 2005 13:27, John Goerzen wrote: > It wasn't from my build tree, but: > > jgoerzen@katherina:/usr/lib/ghc-6.4.1$ grep -ri s34n_info * > Binary file libHSbase.a matches > Binary file libHSdata.a matches > > I unpacked libHSbase.a and found: > > $ grep -ri s34n_info . > Binary file ./String__1.o matches > Binary file ./Posix__6.o matches (this one doesn't match if I omit > -i) > > Identical results from libHSdata.a. > > I thought I would also look at s3eu_info. It too is in libHSbase.a: > > $ grep -r s3eu_info . > Binary file ./Internals__19.o matches > Binary file ./String__1.o matches > > objdump -x String__1.o yields, among other things: > ... > SYMBOL TABLE: > 00000000 l d .text 00000000 .text > 00000068 l O .text 0000000c s34n_info > 00000190 l O .text 00000008 s3et_info > 000000c4 l O .text 00000008 s351_info > 00000160 l O .text 00000008 s3eu_info > 00000000 l d .data 00000000 .data > 00000000 l d .bss 00000000 .bss > 00000000 g O .data 00000004 > ForeignziCziString_zdwpeekCAString_closure > 0000000c g O .text 0000000c > ForeignziCziString_zdwpeekCAString_info 00000000 *UND* > 00000000 GHCziBase_Izh_con_info 00000000 *UND* 00000000 > GHCziBase_Czh_con_info 00000000 *UND* 00000000 > GHCziBase_ZC_con_info 00000000 *UND* 00000000 stg_gc_ut > 00000000 *UND* 00000000 GHCziBase_ZMZN_closure > > Now, I may be totally reading this wrong, but seeing several > references > to Foreign and String made me think of CStrings. That made me > suspicious of this function. You may remember I asked about it on > IRC, > and we thought it was OK: > > msg :: String -> IO () > msg l = > do t <- myThreadId > let disp = (show t) ++ ": " ++ l ++ "\n" > withCStringLen disp (\(c, len) -> hPutBuf stdout c len >> > hFlush stdout) > > This may be a complete red herring, but I just thought I'd bring it > up. > Maybe it's a clue anyway. > > Here's the disassemble output: > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread -1407190096 (LWP 31315)] > 0x080ba84a in s34n_info () > (gdb) disassemble s34n_info > Dump of assembler code for function s34n_info: > 0x080ba834 <s34n_info+0>: mov %edi,0x8(%esp) > 0x080ba838 <s34n_info+4>: mov %edi,%eax > 0x080ba83a <s34n_info+6>: add $0x8,%eax > 0x080ba83d <s34n_info+9>: mov %eax,%edi > 0x080ba83f <s34n_info+11>: cmp 0x5c(%ebx),%eax > 0x080ba842 <s34n_info+14>: ja 0x80ba86b <s34n_info+55> > 0x080ba844 <s34n_info+16>: mov 0x0(%ebp),%edx > 0x080ba847 <s34n_info+19>: mov 0x4(%esi),%eax > 0x080ba84a <s34n_info+22>: cmpb $0x0,(%eax,%edx,1) the crash is here ^^^ it does appear to be something string-related, because that instruction isn't a common one in GHC-generated code - comparing a byte against zero, with a non-trivial addressing mode, looks very much like a string traversal. Do you have any other CString-related code in your program? Cheers, Simon

3 6

RE: Segfaulting programs with GHC 6.4.1
by Simon Marlow 21 Oct '05

21 Oct '05

On 21 October 2005 10:20, John Goerzen wrote: > On Fri, Oct 21, 2005 at 09:52:50AM +0100, Simon Marlow wrote: >> At this stage we need to resort to gdb. Run the version of the >> program compiled with -debug under gdb, and take a look at the >> backtrace when it crashes. Hopefully it'll be somewhere in the RTS, >> if it's somewhere in Haskell code you won't get an informative >> backtrace. > > OK, here's what I've got. There's a little bit here -- no idea if > this provides any clues. In fact, it looks pretty much the same as > when I ran gdb against the core file that it created when it crashed > -- but with the addition of the last few lines. Here are the useful > bits: > > ThreadId 9: quix.us:70:9:/Software/mulinux/Newer > Upload/mulinux-14r0.iso > ThreadId 8: > serpiente.dgsca.unam.mx:70:0:0/noticia_mex_mundo/nacional/febrero94/07/d epo/07febdepo14.txt > [New Thread -1416234064 (LWP 26413)] > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread -1214252112 (LWP 26365)] > 0x080ba84a in s34n_info () > (gdb) bt > #0 0x080ba84a in s34n_info () > #1 0xb7ac8374 in ?? () > #2 0xb7a01910 in ?? () > #3 0xb7ac8764 in ?? () > #4 0xb7a05bac in ?? () > #5 0x00028738 in ?? () > #6 0x08172728 in MainCapability () > #7 0x00000002 in ?? () > #8 0x00000001 in ?? () > #9 0xb7ac266c in ?? () > #10 0x00000001 in ?? () > #11 0xb7ac8738 in ?? () > #12 0x00000000 in ?? () > #13 0x00000000 in ?? () > ... [ thousands of lines of this deleted ] ... > #1872 0x00000000 in ?? () > #1873 0x00000000 in ?? () > #1874 0x08174058 in ?? () > #1875 0x08174058 in ?? () > #1876 0xb7a774b4 in ?? () > #1877 0xb79ff138 in ?? () > #1878 0x08134aa5 in allocBlock () > #1879 0x080ba95c in s3eu_info () A couple more things to try: disassemble s34n_info to see where exactly it crashed, and if there are any calls in there you recognise, and 'grep s34n_info *.o' over your object files to see which object that symbol comes from. Cheers, Simon

2 1

RE: Segfaulting programs with GHC 6.4.1
by Simon Marlow 21 Oct '05

21 Oct '05

On 21 October 2005 09:24, John Goerzen wrote: > On 2005-10-20, John Goerzen <jgoerzen(a)complete.org> wrote: >> I am running GHC 6.4.1 on Linux x86. I have a program that is >> multithreaded, and since the upgrade from GHC 6.4, the program is >> segfaulting. > > Some additional data: > > * Removing -O2 from the compile flags didn't help. (If anything, > it made things worse.) > > * You can see the source for this program with: > > darcs get --partial --tag=bug20051020 > http://darcs.complete.org/gopherbot > > Yes, it is what it sounds like ;-) At this stage we need to resort to gdb. Run the version of the program compiled with -debug under gdb, and take a look at the backtrace when it crashes. Hopefully it'll be somewhere in the RTS, if it's somewhere in Haskell code you won't get an informative backtrace. If it's possible for us to reproduce the bug here, I'll happily take a look. Cheers, Simon

2 1