deps: cherry-pick 2b4c9c1 from v8 upstream #7771
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
nodejs-github-bot
added
the
v8 engine
|
LGTM /cc @nodejs/v8 |
|
LGTM but can you bump the patchlevel in deps/v8/include/v8-version.h and request backports to the 5.2 and 5.3 branches? |
|
LGTM once patchlevel is updated. |
|
Thanks for the reviews. I've updated the patch level. Will also request backports to 5.2/5.3 as well. |
|
LGTM |
|
Not sure how earlier builds were launched but here are ones that seem to be working: https://ci.nodejs.org/job/node-test-commit-v8-linux/209/ |
|
CI runs green. |
|
Going to land now. |
|
Unfortunately it does not seem to apply. Can you rebase. |
|
@mhdawson Conflict in v8-version.h, right? Just reset to HEAD and bump the patchlevel yourself. |
Original commit message:
S390:Update inline asm constraint in test-platform
The GetStackPointer() routine in test-platform uses an inline
assembly code to store the current stack pointer value into a static
variable sp_addr. The existing asm code for S390 uses an ST/STG
instruction, with the memory operand associated with the general ('=g')
constraint to sp_addr.
On GCC 4.8.5, the GCC compiler got confused and treated sp_addr as
an integer operand instead of memory operand, resulting in a store
being emitted that writes to an invalid meory location.
Given the specific store instructions being inlined here, we should
restict the sp_addr operand to explicitly be a memory operand using '=m'
instead of '=g'.
R=bmeurer@chromium.org,jkummerow@chormium.org,rmcilroy@chromium.org,yangguo@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2158523002
Cr-Commit-Position: refs/heads/master@{nodejs#37809}
Fixes: nodejs#7659
|
@mhdawson I rebased and bumped up the patch level. |
|
Ah ok, but joran beat me to it landing now. |
|
Landed as f56cd32 |
mhdawson
pushed a commit
that referenced
this pull request
Jul 19, 2016
Original commit message:
S390:Update inline asm constraint in test-platform
The GetStackPointer() routine in test-platform uses an inline
assembly code to store the current stack pointer value into a static
variable sp_addr. The existing asm code for S390 uses an ST/STG
instruction, with the memory operand associated with the general ('=g')
constraint to sp_addr.
On GCC 4.8.5, the GCC compiler got confused and treated sp_addr as
an integer operand instead of memory operand, resulting in a store
being emitted that writes to an invalid meory location.
Given the specific store instructions being inlined here, we should
restict the sp_addr operand to explicitly be a memory operand using '=m'
instead of '=g'.
R=bmeurer@chromium.org,jkummerow@chormium.org,rmcilroy@chromium.org,yangguo@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2158523002
Cr-Commit-Position: refs/heads/master@{#37809}
Fixes: #7659
PR-URL: #7771
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: Ali Ijaz Sheikh <ofrobots@google.com>
|
Does this need to be backported to v6.x? |
|
@evanlucas No. This fix is S390 specific; v6.x is still using V8 5.0, which doesn't have full S390 support. Unless V8 5.1 lands there.... |
|
@joransiu Could you do the backport request ? Can you please post a link to the related V8 bug here ? |
|
Here's the issue tracking the V8 backports (to 5.2 / 5.3). https://bugs.chromium.org/p/v8/issues/detail?id=5225 |
|
The fix has been backported to V8 5.2 / 5.3. |
2 tasks
targos
pushed a commit
to targos/node
that referenced
this pull request
Jul 26, 2016
Original commit message:
S390:Update inline asm constraint in test-platform
The GetStackPointer() routine in test-platform uses an inline
assembly code to store the current stack pointer value into a static
variable sp_addr. The existing asm code for S390 uses an ST/STG
instruction, with the memory operand associated with the general ('=g')
constraint to sp_addr.
On GCC 4.8.5, the GCC compiler got confused and treated sp_addr as
an integer operand instead of memory operand, resulting in a store
being emitted that writes to an invalid meory location.
Given the specific store instructions being inlined here, we should
restict the sp_addr operand to explicitly be a memory operand using '=m'
instead of '=g'.
R=bmeurer@chromium.org,jkummerow@chormium.org,rmcilroy@chromium.org,yangguo@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2158523002
Cr-Commit-Position: refs/heads/master@{nodejs#37809}
Fixes: nodejs#7659
PR-URL: nodejs#7771
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: Ali Ijaz Sheikh <ofrobots@google.com>
ofrobots
pushed a commit
to ofrobots/node
that referenced
this pull request
Aug 25, 2016
Original commit message:
S390:Update inline asm constraint in test-platform
The GetStackPointer() routine in test-platform uses an inline
assembly code to store the current stack pointer value into a static
variable sp_addr. The existing asm code for S390 uses an ST/STG
instruction, with the memory operand associated with the general ('=g')
constraint to sp_addr.
On GCC 4.8.5, the GCC compiler got confused and treated sp_addr as
an integer operand instead of memory operand, resulting in a store
being emitted that writes to an invalid meory location.
Given the specific store instructions being inlined here, we should
restict the sp_addr operand to explicitly be a memory operand using '=m'
instead of '=g'.
R=bmeurer@chromium.org,jkummerow@chormium.org,rmcilroy@chromium.org,yangguo@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2158523002
Cr-Commit-Position: refs/heads/master@{nodejs#37809}
Fixes: nodejs#7659
PR-URL: nodejs#7771
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: Ali Ijaz Sheikh <ofrobots@google.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Checklist
make -j4 test(UNIX), orvcbuild test nosign(Windows) passesAffected core subsystem(s)
deps
Description of change
Original commit message:
S390:Update inline asm constraint in test-platform
The GetStackPointer() routine in test-platform uses an inline
assembly code to store the current stack pointer value into a static
variable sp_addr. The existing asm code for S390 uses an ST/STG
instruction, with the memory operand associated with the general ('=g')
constraint to sp_addr.
On GCC 4.8.5, the GCC compiler got confused and treated sp_addr as
an integer operand instead of memory operand, resulting in a store
being emitted that writes to an invalid meory location.
Given the specific store instructions being inlined here, we should
restict the sp_addr operand to explicitly be a memory operand using '=m'
instead of '=g'.
R=bmeurer@chromium.org,jkummerow@chormium.org,rmcilroy@chromium.org,yangguo@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2158523002
Cr-Commit-Position: refs/heads/master@{#37809}
Fixes: #7659