March 2006 - Yhc - Haskell.org

Re: [Yhc] Patch: 'Fix reading from past the end of G_markTable in mkt_firstMarked ()'
by Tom Shackell 27 Mar '06

27 Mar '06

Hi Michal, Oh okay, the constant table is a table of constants that are used by a function. For example when a MK_AP is performed it says which function to make an application to by using an index into the constant table. These have to be malloced because you don't know what's in them, or how big they need to be, until the bytecode is loaded. However, a function can indeed have no constants (although it's fairly uncommon). Easiest way is just to add a check before that malloc. Thanks Tom Michał Pałka wrote: > Neil, > > Attached. I think they are 'sometimes zero'. I hope the stack trace > makes it clear to you what happens, as it's almost clear to me. > > This looks like allocating ConstTable of size 0. But what is ConstTable > anyway (are we allocating constants in tables - why?)? > > I'm not telling that calling malloc (0) is inherently bad. As you can > see, malloc allows this. Electric Fence bails out when it sees malloc > (0), but this particular check could be turned off. It all depends on > your policy, whether you allow 0-mallocs or not. > > A heavy-weight approach to sorting this out came to my mind. You define: > void* zmalloc (size_t n) > { > if (n != 0) return malloc (n); > return NULL; > } > > void* nzmalloc (size_t n) > { > assert (n != 0); > return malloc (n); > } > And use one of them depending on what you expect n to be. But wrapping > some mallocs in if (n != 0) {} is also ok IMO. > > Thanks, > Michal > > On Tue, 2006-03-21 at 14:30 +0000, Neil Mitchell wrote: > >>Hi Michal, >> >>Any chance you can send an example of one of these 0-sized mallocs? >>Are they always zero, normally zero or what? >> >>In general though, it would be nice to have Yhc work perfectly (i.e. >>no warnings) with these tools, so its easier to detect real problems, >>so I'd have thought the answer was yes, these need fixing. >> >>Thanks >> >>Neil >> >>On 3/20/06, Michał Pałka <michal.palka(a)poczta.fm> wrote: >> >>>I discovered this using Valgrind and Electric Fence. There are also >>>mallocs of size 0 that are considered errors by efence. Should I attempt >>>to fix them? >>> >>>Michal >>> >>> >>>_______________________________________________ >>>Yhc mailing list >>>Yhc(a)haskell.org >>>http://haskell.org/mailman/listinfo/yhc >>> >>> >>> >>> >>> >>> >>>------------------------------------------------------------------------ >>> >>>#0 0x00002aaaab1d0189 in kill () from /lib/libc.so.6 >>>#1 0x00002aaaaabc5053 in EF_Abort () from /usr/lib/libefence.so.0.0 >>>#2 0x00002aaaaabc4c04 in memalign () from /usr/lib/libefence.so.0.0 >>>#3 0x00002aaaaabc4c97 in malloc () from /usr/lib/libefence.so.0.0 >>>#4 0x0000000000402c98 in mod_loadConstTable (mod=0x2aaaab42efb8, finfo=0x2aaab0a12fb8) at module.c:272 >>>#5 0x0000000000403a4b in mod_loadFun (mod=0x2aaaab42efb8, name=0x2aaab0a14fe4 "Prelude.Num.Prelude.Int.-", obj=0x2aaab0a0cff0) >>> at module.c:439 >>>#6 0x0000000000403cb4 in mod_loadObject (mod=0x2aaaab42efb8, offs=117594, obj=0x2aaab0a0cff0) at module.c:514 >>>#7 0x0000000000402a13 in mod_resolve (module=0x2aaab0a0eff8 "Prelude", item=0x2aaab0a10fe4 "Prelude.Num.Prelude.Int.-") at module.c:209 >>>#8 0x0000000000402f0d in mod_loadConstTable (mod=0x2aaab089cfb8, finfo=0x2aaab0997fb8) at module.c:322 >>>#9 0x0000000000403a4b in mod_loadFun (mod=0x2aaab089cfb8, name=0x2aaab0999ff8 "valid", obj=0x2aaab0991ff0) at module.c:439 >>>#10 0x0000000000403cb4 in mod_loadObject (mod=0x2aaab089cfb8, offs=1475, obj=0x2aaab0991ff0) at module.c:514 >>>#11 0x0000000000402a13 in mod_resolve (module=0x2aaab0993ff8 "Main", item=0x2aaab0995ff8 "valid") at module.c:209 >>>#12 0x0000000000402f0d in mod_loadConstTable (mod=0x2aaab089cfb8, finfo=0x2aaab0989fb8) at module.c:322 >>>#13 0x0000000000403a4b in mod_loadFun (mod=0x2aaab089cfb8, name=0x2aaab098bff8 "queens", obj=0x2aaab0983ff0) at module.c:439 >>>#14 0x0000000000403cb4 in mod_loadObject (mod=0x2aaab089cfb8, offs=1580, obj=0x2aaab0983ff0) at module.c:514 >>>#15 0x0000000000402a13 in mod_resolve (module=0x2aaab0985ff8 "Main", item=0x2aaab0987ff8 "queens") at module.c:209 >>>#16 0x0000000000402f0d in mod_loadConstTable (mod=0x2aaab089cfb8, finfo=0x2aaab097bfb8) at module.c:322 >>>#17 0x0000000000403a4b in mod_loadFun (mod=0x2aaab089cfb8, name=0x2aaab097dff8 "main", obj=0x2aaab0979ff0) at module.c:439 >>>#18 0x0000000000403cb4 in mod_loadObject (mod=0x2aaab089cfb8, offs=1606, obj=0x2aaab0979ff0) at module.c:514 >>>#19 0x0000000000402a13 in mod_resolve (module=0x7fffffecab6c "Main", item=0x41f1b1 "main") at module.c:209 >>>#20 0x00000000004046ee in initGlobals (mainMod=0x7fffffecab6c "Main", mainFunc=0x7fffffec9708, _toplevel=0x7fffffec9710, >>> _driver=0x7fffffec9700) at main.c:120 >>>#21 0x0000000000404880 in init (mainMod=0x7fffffecab6c "Main", mainFunc=0x7fffffec9708, _toplevel=0x7fffffec9710, _driver=0x7fffffec9700) >>> at main.c:145 >>>#22 0x00000000004048de in main (argc=2, argv=0x7fffffec9808) at main.c:171

2 1

Patch: 'Fix reading from past the end of G_markTable in mkt_firstMarked ()'
by Michał Pałka 20 Mar '06

20 Mar '06

I discovered this using Valgrind and Electric Fence. There are also mallocs of size 0 that are considered errors by efence. Should I attempt to fix them? Michal

1 0

AMD64 port complete (hopefully)
by Michał Pałka 19 Mar '06

19 Mar '06

Tom, I have spotted the bug that was crashing the GC on AMD64 and now YHC seems to run stable on that platform. I'm sending the patches that darcs found missing in the official yhc-devel repo. I can't crash yhi anymore. It ran fine on Queens 4x4 test with QUITE_PARANOID turned on and heap size tuned to force garbage collection cycles. I think you can proclaim YHC ported to Linux/AMD64;) Or do you have ideas of other tests to run? Michal

1 0

Re: [Yhc] building yhc on FreeBSD
by David Frech 16 Mar '06

16 Mar '06

If you come up with a version that you want me to test on FreeBSD, just ping me or the list. Cheers, - David On 3/16/06, Andrew Wilkinson <andrewjwilkinson(a)gmail.com> wrote: > On 3/16/06, David Frech <yhc(a)nimblemachines.com> wrote: > > The issue is that autoconf+configure and gcc aren't looking in > > /usr/local/{include,lib} for the libgmp stuff (gmp.h and the > > libraries). > > > > /usr/local is also a standard location under Linux so configure should have > been looking there. I'm not really sure where exactly to look to change > that, but I have been playing around trying to replace the seperate > Windows/Unix build scripts and the evil autoconf/automake hackery by > replacing them with scons. Currently I've got as far as generating config.h > and building yhi and yhc. I just need to try and build the library now. I > haven't talked to Tom about whether he's actually interested in replacing > automake/autoconf but assuming he is I'll ensure the new build scripts look > in the right place :-) > > Andrew > > > _______________________________________________ > Yhc mailing list > Yhc(a)haskell.org > http://haskell.org/mailman/listinfo/yhc > > > -- Life's better on two wheels. http://nimblemachines.com/browse?name=cycl -- Life's better on two wheels. http://nimblemachines.com/browse?name=cycl

1 0

building yhc on FreeBSD
by David Frech 16 Mar '06

16 Mar '06

Folks - I just recently (last night) did a darcs get of the yhc-devel source and tried to build it on a FreeBSD system. I ran into a couple of small problems, easily solved. It should be easy to tweak the config/make setup to work with BSD systems, which put "external" libraries (like gmp) in /usr/local. The issue is that autoconf+configure and gcc aren't looking in /usr/local/{include,lib} for the libgmp stuff (gmp.h and the libraries). I have gmp 4.1.4 installed - probably because I installed GHC - so I was surprised that libgmp wasn't being discovered. I couldn't figure out - in the time that my patience allowed - how to make autoconf do the right thing so I simply commented out the configure checks (which were bombing out and claiming I didn't have a gmp library) and added -I/usr/local/include to CFLAGS and -L/usr/local/lib to LDFLAGS (in yhc-devel/src/runtime/BCKernel/Makefile), and added "-lgmp" to LIBS in the toplevel Makefile.inc. I was able to build everything (using "gmake" - what GNU make is called on BSD systems), and ran "gmake tests" and got 51/51 passes. Hope this helps, - David -- Life's better on two wheels. http://nimblemachines.com/browse?name=cycl

2 1

Libraries
by Neil Mitchell 14 Mar '06

14 Mar '06

Hi, Just to inform everyone, I've got Data.Map and Data.Set going through with Yhc, so maybe self-compiling isn't as far away as everyone (i.e. Me) thought :) The things that are required to get the haskell.org libraries working are: 1) Directory, which requires FFI (Tom is working on this) 2) Delete haskell98 package supplied with Yhc, most of this is in the haskell.org haskell98 package, which needs setting up (should be easy) (I will do this, after the other steps) 3) Move all the heirarchial stuff in yhc-base to Yhc.Internal.* - absolutely everything must go in that namespace, including Prelude etc. Some of the modules want to die (Data.Maybe) some just need moving. Moving most should be easy, moving Prelude will probably be hard. (I will probably need Tom's help for this) 4) Modify the haskell.org base package to be Yhc compatible, the changes should be minimal. In particular Prelude will need to import Yhc.Internal.Prelude. I have some rough patches, some features required and just some general maintenance required. (Some bits are going to be Tom's domain, I can do the rest). This will make haskell98, base and yhc-base all required packages for a default Yhc installation, and all required to build Yhc itself. Thanks Neil

1 0

Can YHC compile itself?
by Adam Megacz 13 Mar '06

13 Mar '06

Hey, just wondering how far YHC is from being able to self-host... anybody have an idea? - a -- PGP/GPG: 5C9F F366 C9CF 2145 E770 B1B8 EFB1 462D A146 C380

2 1

YHC on AMD64
by Michał Pałka 12 Mar '06

12 Mar '06

YHC hackers, I've managed to run hello world with YHC on AMD64. This required changing the definition of UShort type from HALF_TYPE which is 32-bit int to short. The problem lied in mutator.c where jTable variable was meant to contain 2-byte integers but contained 4-byte integers on AMD64 and jumps were calculated wrong. The patch I've attached is only for reference. I don't know what is the correct type for UShort (or maybe jTable shouldn't be UShort * ?). I wanted to run some tests and was pointed to src/tester by Neil. However, all the test failed because of some Makefile problems. Output attached. Do you have any nontrivial code that runs on YHC/i386? I would like to test it on my machine. Thanks, Michal --------------------------------------------------------------------- Toshiba i FIFA World Cup Wygraj bilety i notebooki z Intel Centrino Duo Mobile Technology http://link.interia.pl/f1912

4 9

some initial questions
by Robert Dockins 09 Mar '06

09 Mar '06

Hello YHC hackers, I've been looking pretty closely at YHC and I have a couple of questions: 1) I'm interested in the possibility of doing Java-style verification of bytecode, so I've been studying the bytecode docs. Looking at the bytecodes, I notice that all the jump bytecodes seem to indicate that jumps are always forward jumps. Upon reflection it makes perfect sense, but I want to make sure that is a conscious design decision. It certainly makes the kinds of analysis I'm interested in easier... 2) I notice that concurrency is a big unclaimed todo item. Are there any concrete plans in this direction? I'm sort of interested in this, but before I think about it too much, I was wondering what has and has not been thought about/done so far. Thanks! Rob Dockins

6 9

Yhc bytecode thoughts
by Neil Mitchell 05 Mar '06

05 Mar '06

Hi, This message is probably mainly targeted at Tom, but since we have a mailing list and other people may be interested, I thought I'd send it to everyone. I was looking at compiled bytecode, and I noticed things that might be able to be improved - in rough order of difficulty. I don't think any of these impact on the backend at all, but might make faster code in general. == SLIDE 0 == I noticed some of these, I take it they are a noop? If so, lets peephole them away! Probably one line of code... == JUMP_FALSE -> JUMP_ZERO == If we moved from JUMP_FALSE to JUMP_ZERO (which i take it is the same semantics anyway!) then this could often be used for case statements on two constructors (say lists, for example). Also case on a bool is expanded to a case, if we had JUMP_ZERO this could be collapsed back as a more general transformation. Less code, faster code, happier code. == EVAL; JUMP; RETURN == I noticed a few things that EVAL, then JUMP, then RETURN - of course you could collapse the EVAL to EVAL_RETURN and throw away the jump. Less code, more speed, everyone is happy :) == branch factorisation == I noticed a few cases where two branches both jump to the same place, and execute the same code, but the code before the jump's are the same. These could be factorised into the after the jump bit - less code, same speed, there are possibly more important things before worrying about this... Thanks Neil

2 2