Closed
Bug 928381
Opened 10 years ago
Closed 10 years ago
ctypes/libffi: Fix stack alignment on *BSD/i386
Categories
(Core :: js-ctypes, defect)
Tracking
()
RESOLVED
FIXED
mozilla28
People
(Reporter: gaston, Assigned: gaston)
Details
Attachments
(1 file)
1.93 KB,
patch
|
glandium
:
review+
|
Details | Diff | Splinter Review |
Context: http://sourceware.org/ml/libffi-discuss/2013/msg00127.html This is a patch we've been carrying in the openbsd portstree since a while for all copies of libffi. i'd like to properly push it back to the copy we have within ctypes..
Assignee | ||
Comment 1•10 years ago
|
||
Jan, any hindsight on this or objections ?
Comment 2•10 years ago
|
||
Have these patches (this and bug 928390) been applied upstream?
Assignee | ||
Comment 3•10 years ago
|
||
(In reply to Bobby Holley (:bholley) from comment #2) > Have these patches (this and bug 928390) been applied upstream? the patch from this bug is just pending on the libffi-discuss mailing list, but was written by one of our binutils/toolchain hacker. The patches from the other bug have been locally applied since a while, and i think they were supposed to be pushed back at some point (but i'm not the one taking care of this)
Comment 4•10 years ago
|
||
I don't think it makes sense for Mozilla to act as a middleman for downstream patches. I think we should get them fully applied upstream and then upgrade our in-tree libffi to something more recent (see bug 810631).
Assignee | ||
Comment 5•10 years ago
|
||
Fair point, but there are already a bunch of patches that were applied this way which didnt make it upstream (yet?) iirc, because they dont really seem to care (see https://github.com/atgreen/libffi/issues/42)
Comment 6•10 years ago
|
||
(In reply to Landry Breuil (:gaston) from comment #5) > Fair point, but there are already a bunch of patches that were applied this > way which didnt make it upstream (yet?) iirc Indeed. No question that Mozilla has been lazy on this front. I'm just saying that, at the point when something is being upstreamed, it should go to the source (largely because I don't know enough about libffi to properly review patches to it). Once they're there, I'm happy to either try to upgrade our in-tree libffi, or failing that, add the patch to our local set. > because they dont really seem > to care (see https://github.com/atgreen/libffi/issues/42) Does "they" refer to the libffi folks, or the Mozilla folks?
Assignee | ||
Comment 7•10 years ago
|
||
(In reply to Bobby Holley (:bholley) from comment #6) > (In reply to Landry Breuil (:gaston) from comment #5) > > Fair point, but there are already a bunch of patches that were applied this > > way which didnt make it upstream (yet?) iirc > > Indeed. No question that Mozilla has been lazy on this front. I'm just > saying that, at the point when something is being upstreamed, it should go > to the source (largely because I don't know enough about libffi to properly > review patches to it). Once they're there, I'm happy to either try to > upgrade our in-tree libffi, or failing that, add the patch to our local set. I dont know enough of libffi either, it's just that i'm trying to get rid of patches that: - i apply locally anyway - only affect openbsd > > because they dont really seem > > to care (see https://github.com/atgreen/libffi/issues/42) > > Does "they" refer to the libffi folks, or the Mozilla folks? I consider myself part of "the Mozilla folks" so would have rather used "we" in that case - that was referring to libffi upstream.
Comment 8•10 years ago
|
||
OK. Shifting these patches openbsd into mozilla-central seems kind of a like a wash in terms of global entropy. I think the way forward for anyone willing to expend energy to improve the situation is to press for the inclusion of any downstream patches in libffi proper (doing so with Mozilla's local libffi patches as well would be even more awesome). At that point, we can cleanly upgrade, and nobody needs to keep local patches around. CCing glandium, since he seems to be the one who patch libffi most recently.
Assignee | ||
Comment 9•10 years ago
|
||
I made you a patch 2 weeks ago but i eated it^W^Wforgot to ask for review...
Assignee: nobody → landry
Attachment #826278 -
Flags: review?(mh+mozilla)
Comment 10•10 years ago
|
||
(In reply to Bobby Holley (:bholley) from comment #8) > OK. Shifting these patches openbsd into mozilla-central seems kind of a like > a wash in terms of global entropy. I think the way forward for anyone > willing to expend energy to improve the situation is to press for the > inclusion of any downstream patches in libffi proper (doing so with > Mozilla's local libffi patches as well would be even more awesome). At that > point, we can cleanly upgrade, and nobody needs to keep local patches around. It's kind of a chicken and egg problem. We can't really push all of our patches upstream because they conflict with newer libffi, and we can't upgrade to a newer libffi because our patches don't apply. RyanVM has been trying to get a new libffi working for us, but it breaks windows. So until we actually upgrade libffi, we can't really push much upstream. That being said there is also a number of patches that we took from upstream.
Updated•10 years ago
|
Attachment #826278 -
Flags: review?(mh+mozilla) → review+
Assignee | ||
Comment 11•10 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/96420ca47200
https://hg.mozilla.org/mozilla-central/rev/96420ca47200
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla28
Assignee | ||
Comment 13•10 years ago
|
||
And just for the record, this got commited upstream too in https://github.com/atgreen/libffi/commit/becd754434173032f426d22ffcbfe24f55b3c137
You need to log in
before you can comment on or make changes to this bug.
Description
•