Compiling tamarin-tracing on linux
zbynek.winkler at gmail.com
Mon Jan 7 01:09:19 PST 2008
No need to apologize, I just wanted to check what the current status
is - i.e. is MMgc newer in TC or TT? And what about
actionmonkey-tamarin? Is it super set of TC? Maybe we can get together
a wiki page describing the different mercurial repositories (or update
some existing page). I'd be happy to do that but I do not know enough
at the moment.
The configure.py + manifest.mk is not the primary build system for all
platforms? Somehow I got the impression that it is but looking at the
platform directory I see it just might not be. I will submit what I
have tonight anyway. Would you prefer private email, tamarin-devel
email and/or bugzilla entry with a patch? But please note that the
resulting binary does not work and that for debug build
(--enable-debug) the AvmDebugUnix.cpp is missing (the version from TC
does not seem to be compatible).
How does one build Release or Release-Debugger build with the cross
platform make system? Is "./configure.py --enable-optimize" enough to
get what you call Release build? And what about the Release-Debugger?
On 07/01/2008, Steven Johnson <stejohns at adobe.com> wrote:
> Tamarin-central (TC) is up to date on Linux, but most of the dev work on
> Tamarin-tracing (TT) has been done on Mac OS X and Windows, so the Linux
> build has gotten a little stale -- apologies for that, it's not our
> intention, just a side-effect of the primary dev environments that a handful
> of people at Adobe have been using. (Feel free to submit your Linux fixes as
> a patch!) As to your segfault, I don't know offhand, but I suspect it should
> be something relatively minor, as TT already works on OS X and actually uses
> fewer OS-specific tricks than TC does. We'll try to look at it soon and get
> a working Linux version out.
> TT is intended to pass the same test suites as TC, and should (with just a
> few exceptions), but as you've noticed is quite a bit slower that Tamarin.
> We're concentrating our efforts on improving this (and you can expect
> signficant progress on this front soon), but for now the times you see are
> not unexpected. In the long run, we are pretty confident that TT will
> achieve parity (at least) with TC, with a much lower code and memory-usage
> footprint, but for now, it's pretty pokey. I'd recommend running the tests
> with a Release or Release-Debugger build, which generally can complete in
> 5-10 minutes on a recent Intel machine.
> On 1/6/08 1:27 PM, "Zbynek Winkler" <zbynek.winkler at gmail.com> wrote:
> > Hello,
> > I've read some papers about trace tree code generation and I wanted to
> > check out tamarin-tracing. I tried to compile it on Debian testing
> > with
> > g++ (GCC) 4.2.3 20071123 (prerelease) (Debian 4.2.2-4)
> > I found the */manifest.mk files not up to date so I made some fixes. I
> > also had to fix some warnings (as errors) about unused variables and
> > such. I got to a point of having avmshell executable.
> > However when I run it I get a seg fault. Backtrace from gdb is:
> > (gdb) bt
> > #0 0x080a4929 in nanojit::LIns::resv ()
> > #1 0x08098fa5 in nanojit::Assembler::findRegFor ()
> > #2 0x0809fbc8 in nanojit::Assembler::gen ()
> > #3 0x080a2010 in nanojit::Assembler::assemble ()
> > #4 0x08071526 in avmplus::Interpreter::inner ()
> > #5 0x08074c32 in avmplus::Interpreter::interpScript ()
> > #6 0x0805ba1a in avmplus::AvmCore::initTopLevel ()
> > #7 0x08049a4b in avmshell::Shell::main ()
> > #8 0x08049d5a in main ()
> > Is tamarin-tracing to be expected to work on Linux? The Makefile in
> > platform/unix/ is not up to date either. How everyone compiles
> > tamarin-tracing? I was not able to create a debug build because there
> > is only AvmDebugWin.cpp and nothing corresponding to linux. Is the
> > development going on windows first?
> > Some problems I've found seem to be fixed in tamarin-central. What is
> > the relationship between these two repositories? I thought
> > tamarin-tracing is based on tamarin-central but it seems that some
> > files might have been reverted to some older state...
> > And finally, is there a faster way to test the built executable?
> > Running test/runtests.py seems to be taking forever... but at the end
> > I got 3 (unexpected) failures for tamarin-central (it took 69 min).
> > Thanks.
> > Zbynek
More information about the Tamarin-devel