Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 547612 - dev-lang/php: failures on x32
Summary: dev-lang/php: failures on x32
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Development (show other bugs)
Hardware: AMD64 Linux
: Normal enhancement (vote)
Assignee: PHP Bugs
URL: https://bugs.php.net/bug.php?id=69328
Whiteboard:
Keywords:
: 570792 (view as bug list)
Depends on:
Blocks: x32
  Show dependency tree
 
Reported: 2015-04-24 19:37 UTC by Stuart Shelton
Modified: 2021-11-23 16:50 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stuart Shelton 2015-04-24 19:37:07 UTC
As per upstream bug noted in URL field above:

$ cat add.php
<?php
$l = 2 + 2;
echo "l=$l\n";
?>

$ /var/tmp/portage/dev-lang/php-5.4.40/work/sapis-build/cli/sapi/cli/php add.php
Segmentation fault

x32 compilation succeeds (although the resulting PHP binary is likely no good) with USE="-phar".

dev-lang/php-5.5.24 appears to be fixed, and executes the above code correctly.
Comment 1 Tiago Marques 2016-06-24 22:33:08 UTC
zend_operators need to be patched or you'll eventually hit integer overflows. This is what I've been using since 5.6.13:

https://github.com/tmarques/overlay_x32-abi/blob/master/dev-lang/php/files/zend_operators-x32.patch

For that version it worked fine but the most recent one fails more tests, though it doesn't seem related.

I've asked this to be merged upstream but since PHP 7 was supposed to support x32 better, it has been neglected.
Comment 2 Michael Orlitzky gentoo-dev 2016-10-02 17:05:59 UTC
*** Bug 570792 has been marked as a duplicate of this bug. ***
Comment 3 Michael Orlitzky gentoo-dev 2016-10-02 17:13:40 UTC
Upstream changes are needed to fix this in all PHP versions. I see that Tiago is still working on it:

https://bugs.php.net/bug.php?id=69693
Comment 4 Tiago Marques 2017-02-09 19:35:46 UTC
Hey.

Upstream seems not to care much. Any consideration for applying local patches? These mostly work for PHP 5 but there's new issues with PHP 7 that I haven't been able to solve yet.
Comment 5 Michael Orlitzky gentoo-dev 2017-02-11 00:30:51 UTC
(In reply to Tiago Marques from comment #4)
> Hey.
> 
> Upstream seems not to care much. Any consideration for applying local
> patches? These mostly work for PHP 5 but there's new issues with PHP 7 that
> I haven't been able to solve yet.

How likely is it that the patches will get outdated?

I'm not able to test it, but if there's a way to apply the x32 patches only when the user is actually using x32, I guess it couldn't hurt. On the other hand, I wouldn't hold up a new version of PHP for everyone just because the patchset fails to apply cleanly over the new version. That would likely leave x32 users with a crashing build instead of a buggy binary.

It would be better for everyone if these could go upstream, but I understand how hard it can be to find someone to review and merge them.
Comment 6 Tiago Marques 2017-02-13 10:15:12 UTC
(In reply to Michael Orlitzky from comment #5)
> (In reply to Tiago Marques from comment #4)
> > Hey.
> > 
> > Upstream seems not to care much. Any consideration for applying local
> > patches? These mostly work for PHP 5 but there's new issues with PHP 7 that
> > I haven't been able to solve yet.
> 
> How likely is it that the patches will get outdated?
> 
> I'm not able to test it, but if there's a way to apply the x32 patches only
> when the user is actually using x32, I guess it couldn't hurt. On the other
> hand, I wouldn't hold up a new version of PHP for everyone just because the
> patchset fails to apply cleanly over the new version. That would likely
> leave x32 users with a crashing build instead of a buggy binary.
> 
> It would be better for everyone if these could go upstream, but I understand
> how hard it can be to find someone to review and merge them.

I agree. As it is, since there is no x32 specific ebuild masking, this causes random failures when integers overflow. These patches run x86 assembly vs x86-64, which fixes overflows. I have not coded improved x32 mode assembly and PHP probably needs further patching to use the extra registers.

Automated testing shows mostly improvements vs x86 assembly. This is due to x32's 64bit time values, which causes automated testing that was expecting overflows to now fail (as it doesn't overflow anymore).

I have been also running the code in a production environment with no ill effects to point out.

The patches are not likely to be outdated, as they alter a part of the code that is rarely - if ever - changed. I have mostly been updating my local ebuilds when a new version comes out. I'll be updating this to the latest PHP 5 this week and post an ebuild.
Comment 7 Michael Orlitzky gentoo-dev 2021-09-01 19:19:09 UTC
I don't suppose this commit fixed your problem?

  https://github.com/php/php-src/pull/3665

In any case, I think we have to give up on this bug. The x32 sub-profile is nearly dead in Gentoo, with the only changes in the past few years being to mask the growing list of packages that don't work with it.

Considering that you may be the only users of both x32 and PHP (if you are still using them) the risks of custom-patching everyone's PHP outweigh the benefits.
Comment 8 Tiago Marques 2021-11-23 16:34:32 UTC
I mostly agree with your comments.

I had to stop working on this for a (good) while. Moved to PHP 7.x and couldn't find a way to patch it.
Though the suggested patch looks the same approach, though it isn't correct. x32 code is x64 code (calling conventions) and not x86-32, which is what that patch does.
Such patch is also lacking without updated tests, as some will fail on x32 despite having the right output.

Right now I would mark this as "needinfo" while I have a look at it, if you may.

---

In an ideal world, x32 profile would exist and specific apps like games or workstation software would only work and compile as 64bit apps - it is a waste to have browser tabs or other software using more resources for no good reason, while being slower due to cache trashing.
On Windows I've recently tested a Core 2nd gen chip that was 10-15% faster on Firefox x86-32 vs x86-64, which would be slower than x32. There are more CPUs like that.

The problem in Gentoo right now is that apps that support ABI_X86 have an immutable x32 - "64 (x32)" - value that also builds x86-64 versions by default. This means one can't disable broken apps and use 64bit versions.
Going forward this would be a problem for software that would require addressing more than 4GiB.

I got stuck on building 'rust' and will keep having a look at this and PHP when I can.
Comment 9 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2021-11-23 16:42:37 UTC
(In reply to Tiago Marques from comment #8)
> The problem in Gentoo right now is that apps that support ABI_X86 have an
> immutable x32 - "64 (x32)" - value that also builds x86-64 versions by
> default. This means one can't disable broken apps and use 64bit versions.
> Going forward this would be a problem for software that would require
> addressing more than 4GiB.
> 
> I got stuck on building 'rust' and will keep having a look at this and PHP
> when I can.

FWIW, you can unforce that 64 in profiles if you want to.
Comment 10 Tiago Marques 2021-11-23 16:49:01 UTC
> FWIW, you can unforce that 64 in profiles if you want to.

I know, tks.

I meant the x32 is immutable, so you can't build browsers or other software in 64bit while running desktop and system software in x32. On 64bit one has an innaccessible x32 flag:

ABI_X86="(64) -32 (-x32)"

I managed to get 64 bit binary packages working, not from Portage, but it was hard to track the dependencies for that and get them built.
Comment 11 Tiago Marques 2021-11-23 16:50:21 UTC
To clarify, if you're on x32 and some package (like rust) is broken, you can't just build the x86-64/amd64 ABI version and ignore the x32 ABI one.