Closed
Bug 1491098
Opened 6 years ago
Closed 5 years ago
Link libgmp into SpiderMonkey, to support BigInt
Categories
(Core :: JavaScript Engine, enhancement, P5)
Core
JavaScript Engine
Tracking
()
RESOLVED
INVALID
People
(Reporter: jorendorff, Unassigned)
References
Details
Attachments
(2 obsolete files)
No description provided.
Reporter | ||
Updated•6 years ago
|
Blocks: js-bigint
Priority: -- → P1
Summary: libgmp → Link libgmp into SpiderMonkey, to support BigInt
Reporter | ||
Comment 1•6 years ago
|
||
See js/src/vm/BigIntType.{h,cpp} for all places where libgmp is used. This code is currently behind #ifdef ENABLE_BIGINT. (And as a result, it's a bit dodgy to find using SearchFox.) Background: BigInt is a new standard-track JS feature. Until now, JS has only had floating-point numbers. BigInt adds arbitrary-precision integers. This is useful for cryptography, codecs, interacting with Wasm -- anywhere you'd use a 64-bit int. Also handy when using JS as a compilation target for source languages that have real integers. Robin Templeton of Igalia is implementing it for SpiderMonkey. We're in the process of landing those patches.
Comment 2•6 years ago
|
||
We've been discussing this a bit on IRC, but I'll summarize here for the record: * libgmp is GPL/LGPL licensed, so we can't statically link it. This was discussed a bit in bug 1366287. * We have precedent for this, we currently ship a `liblgpllibs` shared library with Firefox with other LGPL licensed code: https://dxr.mozilla.org/mozilla-central/source/config/external/lgpllibs/moz.build * We don't currently have anything that does this for Spidermonkey, though, so we'd have to sort out the issues there. This would likely mean just linking libgmp into `liblgpllibs` for full browser builds and linking the JS shell against that lib as well, and then figuring something out for standalone JS builds. (Supporting `--with-system-gmp` would probably make life easier for embeddors.) * Dynamically linking this code does mean that there are performance implications: we'll lose out on inlining and LTO between Spidermonkey and GMP at the very least.
Reporter | ||
Comment 4•6 years ago
|
||
Just chatted with Michael on IRC. Let's put this on hold, in light of bug 1494346. Currently, I expect we will WONTFIX this. We'll know in a few weeks' time.
Comment 5•6 years ago
|
||
Updated•6 years ago
|
Attachment #9016725 -
Attachment is obsolete: true
Comment 6•6 years ago
|
||
MozReview-Commit-ID: USQbjPW2KC Bug 1491098 - Import files generated during gmp build. These are cross-platform. Another option would be to generate these via HostSimplePrograms, but that seems to only work well with .c files in the same directory as the moz.build file, so that would also require some mozbuild work. MozReview-Commit-ID: 11tn7xN4rJX Bug 1491098 - Add gmp moz.yaml file MozReview-Commit-ID: HqFBs4ziGbl Bug 1491098 - Add gmp moz.build files (WIP) Most of the moz.build files are created manually by analyzing what files are built during a normal './configure && make' build of the upstream libgmp library. The exceptions are mpn/moz.build and mpn2/moz.build, which are auto-generated from config_links.py and the config.status file generated by libgmp's configure. The mpn directory is special because: 1) It contains platform-dependent code 2) It compiles some .c files multiple times with different -D flags (eg: sec_aors_1.c is compiled as sec_sub_1 and sec_add_1) 3) It contains .asm files, which are compiled by first preprocessing the .asm with an m4 wrapper script (m4-ccas). Part 3 is not implemented yet in this patch, as it is a WIP. Additionally, the mpn-generated moz.build files will need to be generated for each platform, and stored in platform-specific directories. (Eg: mpn/moz.build should really be mpn/linux.mozbuild, and mpn/moz.build can include the right file based on the platform). I was planning to get Linux working first and then extending to other platforms. MozReview-Commit-ID: ARnSpbeoaDM
Comment 7•6 years ago
|
||
I tried to attach my WIP in case we need to come back to this, but I couldn't get the actual gmp source import patch to work (bugzilla complained that it's too large, and phabricator had some issue with UTF-8 or something). In any case, most of the remaining work is in finishing up the gmp/mpn moz.build files to support .asm (with it's m4-ccas wrapper script), and also split up the mpn moz.build files to support other platforms, since each platform has its own specific set of files that it compiles in this directory. The config_links.py script is intended to generate these files from each platform's config.status file (which means we need to run configure on each platform when importing a new libgmp). I think all of the .c code currently compiles, though I haven't yet diffed them with a regular gmp build to make sure that everything is compiling correctly.
Comment 8•6 years ago
|
||
I pushed the 5 commits to github just in case: https://github.com/mshal/gecko-dev/commits/bug-libgmp
Assignee: mshal → nobody
Reporter | ||
Updated•6 years ago
|
Priority: P1 → P5
Comment 9•5 years ago
|
||
Closing as invalid, given bug 1502797. We will be cleaning out the remaining GMP mentions in the build system for FF67.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → INVALID
Updated•5 years ago
|
Attachment #9016726 -
Attachment is obsolete: true
You need to log in
before you can comment on or make changes to this bug.
Description
•