there's a number of pieces which would need to be updated to support x32, so probably want to have this be a tracking bug and open sep bugs for each piece (like one just for gn).

last i looked, v8 didn't support x32 at all, and was the largest reason i stalled on doing an x32 build (with the second being the multimedia/ffmpeg layers).  but it looks like indeed that port happened and i just missed it:
https://codereview.chromium.org/18014003

True. I'm not sure how tracking bugs work in this bug tracking system, however.

And yes, although v8 very recently depublished x32 support for some reason. I opened a bug in v8 about that: https://bugs.chromium.org/p/v8/issues/detail?id=5248

you might not be able to see the extended fields, but there are "blocked on" and "blocking" fields where we can list other bugs this one depends on.  a "tracking bug" is largely a convention rather than something that is in the bug system explicitly.

 Issue v8:5248  has been merged into this issue.

What is the use-case you try to accomplish by using the x32 port?

My use-case is a low-memory (786 MiB) amd64 netbook. It works much better using an x32 userland compared to an amd64 one. All the needed bits for desktop usage already work on x32, and a good web browser is the last missing piece (a crucial one, considering that the net is the main reason to have a netbook).

The x32 port is an unsupported port which means the V8 team is not maintaining it. The information posted by jkummerow@ in the other issue is correct, AFAIK x32 is currently also scheduled for deletion.

Li from the Intel team did coordinate the x32 port AFAIK. Do you have any update on this Li?

The Error: gyp: Undefined variable platform_heap_asm_files could be caused by build files not updated to support for x32.  I believe that all the build files did not have x32 support.

Please do not axe support of x32 abi.  There is currently no HTML5 browsers that support x32 abi officially for all the major browser engines.  I have a working Firefox 45 for x32 abi and plan to expand support to Chromium for the Gentoo muslx32 (musl libc and x32 abi) profile on my overlay (https://github.com/orsonteodoro/muslx32).

I have fixed the internal dependencies for x32 except for v8 for Chromium.  That needs to be fixed.  I will push those changes on my repo for others to try to fix.  The gdb backtrace for the problem is below.

output of `gdb ./mksnapshot`:
http://pastebin.com/rtgWxKck

output of `gdb ./mksnapshot --random-seed 314159265 --startup_blob ../../out/Debug/snapshot_blob.bin ""`:
http://pastebin.com/1xU0JAvY

I will be putting a copy of port on my 256mb Sempron 2600+ backup computer.  Low end early adopters of 64-bit cpus would probably try this.  

ebuild to inspect to determine which patches to use:  
https://github.com/orsonteodoro/muslx32/blob/master/www-client/chromium/chromium-52.0.2743.116.ebuild

patches: 
https://github.com/orsonteodoro/muslx32/tree/master/www-client/chromium/files

If you can create a patch to fix the problem, I suspect somebody from v8-x87-ports@googlegroups.com can review them.

The V8 core team unfortunately cannot currently support this because we don't have the bandwidth (and hardware).

erm, you most certainly have the hardware :).  x32 is an ABI that works with any x86_64 CPU ... which is to say, the vast majority of CPU's Intel & AMD have made in the last decade.

whether you have an OS set up to easily test that is a diff question.  you'd need a recentish kernel (linux-3.4+, so one from the last 4 years) with the X32 ABI option turned on.  then you could "just" download a Gentoo stage3 and chroot into and bam -- native x32 env.

you're certainly correct on the bandwidth aspect though :).

In fact, Debian has an x32 port too, and it even has a convenient set of CDs for testing that (including a graphical one): http://debian-x32.org/#debian-installer

Sorry, meant platform.

Closing this bug for mentioned reasons. I contacted the Intel people to ping this thread.

Michael's mark is make sense from my point of view

I am still working on this by myself.

I started patching from commit e6716a300970387285a6620dc637ebd199563643 dec 22 2014 3.30.33.11 and worked up to 5.3.204.  My patch were mostly partial reverse patches.

I did a git bisect on the errors and I found that there were more than 12 breakages.  Here is list where it breaks:

commit 1 cc3337c1c2d0cff54fd18afc495ed1e102e6da34 revert
commit 2a https://chromium.googlesource.com/v8/v8/+/801f1b6de81bc1629e6bf35642cfb5fafb15833e
commit 2b 81e131ce4889205570e870cf50c55c7ad61aa376
commit 3 ed2be747ad13746797b655fa4f5c23dc6b0ef3e3 revert
commit 4 5a0df034d14674e789c447161fec96d3cfa836a5
commit 5 bc8f9a78f05c7a9dce0a112835d797d8082749eb
commit 6 473280f82a260f5e07f7ae2649e74732d686389f
commit 7 fa570e55b623c74245945e3bdda042df1bf6a196
commit 8 04c8c11ee569a41d4b07839154eb0c718ff6e381
commit 9 02c8b6f7f0f8801f0cdc33bef576e3b0c3db394e
commit 10 eff24bef5c0f071008bdd4bcee3a86384e90c90b
commit 11 25af5d3d325f3a9aced80fee02df29155b4c695e
commit 12 c8ac0d8693f559795eeb3f3aaf386dde166fb2ab


The patch below is good for 5.3.201.
https://gist.github.com/orsonteodoro/f771c4b2105c69c6d9f885d9dc8dd372

I am working towards version 5.3.332 so I can get Chromium to work.  I am currently trying to bisect the next one but stuck right now.  If you find a better fix to my patch, then post or leave a message on my github.

It's a real pity no effort goes into not breaking x86-64 ILP32 within v8, especially since it was working.  I can understand there's no interest from the core developers to test and optimize the code for what is perceived as niche platform, but taking it into account is much easier for the author of new code than it is for anybody who tries to fix all the breakage!  I've been working on this for a few weeks now, after giving up with a previous effort a few years ago, with the goal of porting Chromium, qtwebengine and nodejs to x32, but it's not easy.

When I say perceived as niche; it's worth pointing out that most mainstream Linux distributions have x32 enabled at kernel and toolchain level, so are able to compile and use x32 binaries, even if userspace library coverage is minimal to non-existent.  I've been trying to bring up full Gentoo x32 desktop and server systems for many years now, most things are working really well.