Status

()

RESOLVED FIXED
9 years ago
9 years ago

People

(Reporter: graydon, Assigned: graydon)

Tracking

Trunk
Points:
---
Bug Flags:
wanted1.9.2 +
in-testsuite -

Firefox Tracking Flags

(status1.9.2 beta1-fixed)

Details

(Whiteboard: fixed-in-tracemonkey)

Attachments

(1 attachment)

(Assignee)

Description

9 years ago
Created attachment 401557 [details] [diff] [review]
Fix the breakage, further detach from tracemonkey environment

Poor old lirasm took a beating during this merge. The attached patch fixes the worst of the differences, as far as I can tell. It builds and passes its tests again anyway.

I'll have a go at a standalone makefile and configure script for the nanojit-central repository next.
Attachment #401557 - Flags: review?(jorendorff)
Attachment #401557 - Flags: review?(jorendorff) → review+
Comment on attachment 401557 [details] [diff] [review]
Fix the breakage, further detach from tracemonkey environment

r=me, no real comments.

>-VPATH		= @srcdir@
>+
>+VPATH		= $(srcdir)
>+VPATH		+= $(srcdir)/../nanojit

I don't really know what this does.

...I take it LIR_loop has been replaced by LIR_x and a patch() after compilation?

>-    AbiKind _abi;
>-    if (abi == "fastcall")
>+    AbiKind _abi = ABI_CDECL;

It seems like _abi is always assigned below. If so, I'd be happier without this initialization, as the compiler can then warn usefully if we introduce a bug.

>-    for (size_t i = 0; i < mCallInfos.size(); ++i)
>-        delete mCallInfos[i];

I guess the new allocator is an arena that gets blown away all at once later? Do you need to explicitly call any destructors, then?
Can the mLabelMap and so forth just be located in the Lirasm instead of being allocated?
(Assignee)

Comment 2

9 years ago
Thanks. In answer to your questions:

The VPATH addition accompanies the change to building lirasm with an explicit list of object files compiled "from nanojit", rather than linked against libjs. There is no dependence on the surrounding JS environment anymore (I hope).

The _abi change eliminates a "possible use before def" warning; the compiler is not smart enough to know that the bad() call in the else block is aborting.

The exact location of most of the auxiliary objects can change now, yes. This patch was an attempt at minimal updates to get it working again. A more extensive update would probably move the ownership around a bit, but I'm leaving that problem for another day.
(Assignee)

Comment 3

9 years ago
Oh, and yes, LIR_loop turned into ... a LIR_j I believe.
(Assignee)

Comment 4

9 years ago
http://hg.mozilla.org/tracemonkey/rev/2371aa917202
Whiteboard: fixed-in-tracemonkey

Comment 5

9 years ago
http://hg.mozilla.org/mozilla-central/rev/2371aa917202
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED

Comment 6

9 years ago
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/8a5bccdbb7d0
status1.9.2: --- → beta1-fixed
Flags: wanted1.9.2+
(Assignee)

Updated

9 years ago
Flags: in-testsuite-
You need to log in before you can comment on or make changes to this bug.