Skip to content
This repository has been archived by the owner on Oct 16, 2021. It is now read-only.

Stack arguments wrong for <JS Function InstantiateFunction> - trace output differs on PPC #1

Closed
andrewlow opened this issue Aug 27, 2013 · 2 comments
Closed

Stack arguments wrong for <JS Function InstantiateFunction> - trace output differs on PPC #1

andrewlow opened this issue Aug 27, 2013 · 2 comments

Comments

@andrewlow
Copy link
Collaborator

Found this while trying to resolve NPM issues.

Build node on Intel & PPC the same way

PPC

./configure --debug --dest-cpu=ppc; make -j20

Intel

./configure --debug --dest-cpu=ia32; make -j7

Now run the following on both.

./node --trace deps/npm/bin/npm-cli.js install url | head -2

Intel output

$ ./node --trace deps/npm/bin/npm-cli.js install url | head -2 1: Instantiate+59(this=0x31f29af9 <JS Object>, 0x31f34711 <FunctionTemplateInfo>, 0x31f08091 <undefined>) { 2: InstantiateFunction+64(this=0x31f29af9 <JS Object>, 0x31f34711 <FunctionTemplateInfo>, 0x31f08091 <undefined>) {

PPC output

$ ./node --trace deps/npm/bin/npm-cli.js install url | head -2 1: Instantiate+88(this=0x9a829ae9 <JS Object>, 0x9a8346e5 <FunctionTemplateInfo>, 0x9a808091 <undefined>) { 2: InstantiateFunction+108(this=0x9a808091 <undefined>, 0x9a8346e5 <FunctionTemplateInfo>, 0x9a808091 <undefined>) {

If you look carefully - you'll notice that the value of this should be <JS Object> but is <undefined> on PPC. I'm sort of surprised anything works.
@andrewlow
Copy link
Collaborator Author

It appears that the ARM simulator also exhibits the same issue. Since the PPC V8 port started from the ARM as a base, it appears we've duplicated this oddity.

I wonder if this has any impact on the accuracy of the runtime? I may be chasing a red-herring.

@andrewlow
Copy link
Collaborator Author

I'm going to close this - clearly it is not causing problems with any of the tests.

@gireeshpunathil gireeshpunathil mentioned this issue Feb 7, 2014
Closed
@jussikan jussikan mentioned this issue Apr 10, 2014
Open
@gireeshpunathil gireeshpunathil mentioned this issue May 9, 2014
Closed
shahidhs added a commit to shahidhs/node that referenced this issue May 8, 2015
@shahidhs
Update configure
1c15120 
After running './configure' on s390x architecture VM, I was getting following output:

bash-4.3# uname -rvmpio
3.10.0-229.1.2.el7.s390x ibmruntimes#1 SMP Fri Mar 6 17:14:40 EST 2015 s390x s390x s390x GNU/Linux

bash-4.3# ./configure
{ 'target_defaults': { 'cflags': [],
                       'default_configuration': 'Release',
                       'defines': [],
                       'include_dirs': [],
                       'libraries': []},
  'variables': { 'clang': 0,
                 'gcc_version': 49,
                 'host_arch': 's390',
                 'node_byteorder': 'big',
                 'node_install_npm': 'true',
                 'node_prefix': '',
                 'node_shared_cares': 'false',
                 'node_shared_http_parser': 'false',
                 'node_shared_libuv': 'false',
                 'node_shared_openssl': 'false',
                 'node_shared_v8': 'false',
                 'node_shared_zlib': 'false',
                 'node_tag': '',
                 'node_unsafe_optimizations': 0,
                 'node_use_dtrace': 'false',
                 'node_use_etw': 'false',
                 'node_use_openssl': 'true',
                 'node_use_perfctr': 'false',
                 'node_use_systemtap': 'false',
                 'openssl_no_asm': 0,
                 'python': '/usr/bin/python',
                 'target_arch': 's390',
                 'v8_enable_gdbjit': 0,
                 'v8_no_strict_aliasing': 1,
                 'v8_use_snapshot': 'true',
                 'want_separate_host_toolset': 0}}
creating  ./config.gypi
creating  ./config.mk
bash-4.3#


As we could see, the configure script has returned me incorrect architecture i.e. 's390' instead of 's390x'. I got this behavior for Fedora21, RHEL7, SLES12 and MCP8 OS. This causes 'make' fail as it tries to build for 's390' instead on 's390x'.

I am proposing the mentioned changes for fixing the issue.

Below is the output when I run the updated './configure' script:

bash-4.3# ./configure
{ 'target_defaults': { 'cflags': [],
                       'default_configuration': 'Release',
                       'defines': [],
                       'include_dirs': [],
                       'libraries': []},
  'variables': { 'clang': 0,
                 'gcc_version': 49,
                 'host_arch': 's390x',
                 'node_byteorder': 'big',
                 'node_install_npm': 'true',
                 'node_prefix': '',
                 'node_shared_cares': 'false',
                 'node_shared_http_parser': 'false',
                 'node_shared_libuv': 'false',
                 'node_shared_openssl': 'false',
                 'node_shared_v8': 'false',
                 'node_shared_zlib': 'false',
                 'node_tag': '',
                 'node_unsafe_optimizations': 0,
                 'node_use_dtrace': 'false',
                 'node_use_etw': 'false',
                 'node_use_openssl': 'true',
                 'node_use_perfctr': 'false',
                 'node_use_systemtap': 'false',
                 'openssl_no_asm': 0,
                 'python': '/usr/bin/python',
                 'target_arch': 's390x',
                 'v8_enable_gdbjit': 0,
                 'v8_no_strict_aliasing': 1,
                 'v8_use_snapshot': 'true',
                 'want_separate_host_toolset': 0}}
creating  ./config.gypi
creating  ./config.mk
bash-4.3#

Now it correctly identifies the host architecture for s390x.

Thanks.
@shahidhs shahidhs mentioned this issue May 11, 2015
Merged
richardlau pushed a commit that referenced this issue Jun 23, 2015
@shahidhs @richardlau
Update configure
6965707 
After running './configure' on s390x architecture VM, I was getting following output:

bash-4.3# uname -rvmpio
3.10.0-229.1.2.el7.s390x #1 SMP Fri Mar 6 17:14:40 EST 2015 s390x s390x s390x GNU/Linux

bash-4.3# ./configure
{ 'target_defaults': { 'cflags': [],
                       'default_configuration': 'Release',
                       'defines': [],
                       'include_dirs': [],
                       'libraries': []},
  'variables': { 'clang': 0,
                 'gcc_version': 49,
                 'host_arch': 's390',
                 'node_byteorder': 'big',
                 'node_install_npm': 'true',
                 'node_prefix': '',
                 'node_shared_cares': 'false',
                 'node_shared_http_parser': 'false',
                 'node_shared_libuv': 'false',
                 'node_shared_openssl': 'false',
                 'node_shared_v8': 'false',
                 'node_shared_zlib': 'false',
                 'node_tag': '',
                 'node_unsafe_optimizations': 0,
                 'node_use_dtrace': 'false',
                 'node_use_etw': 'false',
                 'node_use_openssl': 'true',
                 'node_use_perfctr': 'false',
                 'node_use_systemtap': 'false',
                 'openssl_no_asm': 0,
                 'python': '/usr/bin/python',
                 'target_arch': 's390',
                 'v8_enable_gdbjit': 0,
                 'v8_no_strict_aliasing': 1,
                 'v8_use_snapshot': 'true',
                 'want_separate_host_toolset': 0}}
creating  ./config.gypi
creating  ./config.mk
bash-4.3#

As we could see, the configure script has returned me incorrect architecture i.e. 's390' instead of 's390x'. I got this behavior for Fedora21, RHEL7, SLES12 and MCP8 OS. This causes 'make' fail as it tries to build for 's390' instead on 's390x'.

I am proposing the mentioned changes for fixing the issue.

Below is the output when I run the updated './configure' script:

bash-4.3# ./configure
{ 'target_defaults': { 'cflags': [],
                       'default_configuration': 'Release',
                       'defines': [],
                       'include_dirs': [],
                       'libraries': []},
  'variables': { 'clang': 0,
                 'gcc_version': 49,
                 'host_arch': 's390x',
                 'node_byteorder': 'big',
                 'node_install_npm': 'true',
                 'node_prefix': '',
                 'node_shared_cares': 'false',
                 'node_shared_http_parser': 'false',
                 'node_shared_libuv': 'false',
                 'node_shared_openssl': 'false',
                 'node_shared_v8': 'false',
                 'node_shared_zlib': 'false',
                 'node_tag': '',
                 'node_unsafe_optimizations': 0,
                 'node_use_dtrace': 'false',
                 'node_use_etw': 'false',
                 'node_use_openssl': 'true',
                 'node_use_perfctr': 'false',
                 'node_use_systemtap': 'false',
                 'openssl_no_asm': 0,
                 'python': '/usr/bin/python',
                 'target_arch': 's390x',
                 'v8_enable_gdbjit': 0,
                 'v8_no_strict_aliasing': 1,
                 'v8_use_snapshot': 'true',
                 'want_separate_host_toolset': 0}}
creating  ./config.gypi
creating  ./config.mk
bash-4.3#

Now it correctly identifies the host architecture for s390x.

Thanks.
Conflicts:
	configure
@dpasupathi dpasupathi mentioned this issue Jul 17, 2015
Closed
gibfahn pushed a commit that referenced this issue Aug 30, 2016
@fhinkel
deps: cherry-pick 7bd24767 from v8 upstream (v6.x)
08e2b04 
Original commit message:

    Version 5.1.281.65 (cherry-pick)

    Merged 85b8c2dc4aee1031ac02f9d7c02d5c1aa76bc2ba

    Fix observable array access when formatting stack trace.

    BUG=chromium:617527
    LOG=N
    R=hablich@chromium.org

    Review URL: https://codereview.chromium.org/2051383002 .

    Cr-Commit-Position: refs/branch-heads/5.1@{#76}
    Cr-Branched-From: 167dc63b4c9a1d0f0fe1b19af93644ac9a561e83-refs/heads/5.1.281@{#1}
    Cr-Branched-From: 03953f52bd4a184983a551927c406be6489ef89b-refs/heads/master@{#35282}

PR-URL: nodejs/node#8078
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Ali Ijaz Sheikh <ofrobots@google.com>
jBarz pushed a commit that referenced this issue Nov 3, 2016
@shahidhs
Update configure
57f52f0 
After running './configure' on s390x architecture VM, I was getting following output:

bash-4.3# uname -rvmpio
3.10.0-229.1.2.el7.s390x #1 SMP Fri Mar 6 17:14:40 EST 2015 s390x s390x s390x GNU/Linux

bash-4.3# ./configure
{ 'target_defaults': { 'cflags': [],
                       'default_configuration': 'Release',
                       'defines': [],
                       'include_dirs': [],
                       'libraries': []},
  'variables': { 'clang': 0,
                 'gcc_version': 49,
                 'host_arch': 's390',
                 'node_byteorder': 'big',
                 'node_install_npm': 'true',
                 'node_prefix': '',
                 'node_shared_cares': 'false',
                 'node_shared_http_parser': 'false',
                 'node_shared_libuv': 'false',
                 'node_shared_openssl': 'false',
                 'node_shared_v8': 'false',
                 'node_shared_zlib': 'false',
                 'node_tag': '',
                 'node_unsafe_optimizations': 0,
                 'node_use_dtrace': 'false',
                 'node_use_etw': 'false',
                 'node_use_openssl': 'true',
                 'node_use_perfctr': 'false',
                 'node_use_systemtap': 'false',
                 'openssl_no_asm': 0,
                 'python': '/usr/bin/python',
                 'target_arch': 's390',
                 'v8_enable_gdbjit': 0,
                 'v8_no_strict_aliasing': 1,
                 'v8_use_snapshot': 'true',
                 'want_separate_host_toolset': 0}}
creating  ./config.gypi
creating  ./config.mk
bash-4.3#

As we could see, the configure script has returned me incorrect architecture i.e. 's390' instead of 's390x'. I got this behavior for Fedora21, RHEL7, SLES12 and MCP8 OS. This causes 'make' fail as it tries to build for 's390' instead on 's390x'.

I am proposing the mentioned changes for fixing the issue.

Below is the output when I run the updated './configure' script:

bash-4.3# ./configure
{ 'target_defaults': { 'cflags': [],
                       'default_configuration': 'Release',
                       'defines': [],
                       'include_dirs': [],
                       'libraries': []},
  'variables': { 'clang': 0,
                 'gcc_version': 49,
                 'host_arch': 's390x',
                 'node_byteorder': 'big',
                 'node_install_npm': 'true',
                 'node_prefix': '',
                 'node_shared_cares': 'false',
                 'node_shared_http_parser': 'false',
                 'node_shared_libuv': 'false',
                 'node_shared_openssl': 'false',
                 'node_shared_v8': 'false',
                 'node_shared_zlib': 'false',
                 'node_tag': '',
                 'node_unsafe_optimizations': 0,
                 'node_use_dtrace': 'false',
                 'node_use_etw': 'false',
                 'node_use_openssl': 'true',
                 'node_use_perfctr': 'false',
                 'node_use_systemtap': 'false',
                 'openssl_no_asm': 0,
                 'python': '/usr/bin/python',
                 'target_arch': 's390x',
                 'v8_enable_gdbjit': 0,
                 'v8_no_strict_aliasing': 1,
                 'v8_use_snapshot': 'true',
                 'want_separate_host_toolset': 0}}
creating  ./config.gypi
creating  ./config.mk
bash-4.3#

Now it correctly identifies the host architecture for s390x.

Thanks.
Conflicts:
	configure
jBarz pushed a commit that referenced this issue Nov 4, 2016
@shahidhs @jBarz
Update configure
a5854b4 
After running './configure' on s390x architecture VM, I was getting following output:

bash-4.3# uname -rvmpio
3.10.0-229.1.2.el7.s390x #1 SMP Fri Mar 6 17:14:40 EST 2015 s390x s390x s390x GNU/Linux

bash-4.3# ./configure
{ 'target_defaults': { 'cflags': [],
                       'default_configuration': 'Release',
                       'defines': [],
                       'include_dirs': [],
                       'libraries': []},
  'variables': { 'clang': 0,
                 'gcc_version': 49,
                 'host_arch': 's390',
                 'node_byteorder': 'big',
                 'node_install_npm': 'true',
                 'node_prefix': '',
                 'node_shared_cares': 'false',
                 'node_shared_http_parser': 'false',
                 'node_shared_libuv': 'false',
                 'node_shared_openssl': 'false',
                 'node_shared_v8': 'false',
                 'node_shared_zlib': 'false',
                 'node_tag': '',
                 'node_unsafe_optimizations': 0,
                 'node_use_dtrace': 'false',
                 'node_use_etw': 'false',
                 'node_use_openssl': 'true',
                 'node_use_perfctr': 'false',
                 'node_use_systemtap': 'false',
                 'openssl_no_asm': 0,
                 'python': '/usr/bin/python',
                 'target_arch': 's390',
                 'v8_enable_gdbjit': 0,
                 'v8_no_strict_aliasing': 1,
                 'v8_use_snapshot': 'true',
                 'want_separate_host_toolset': 0}}
creating  ./config.gypi
creating  ./config.mk
bash-4.3#

As we could see, the configure script has returned me incorrect architecture i.e. 's390' instead of 's390x'. I got this behavior for Fedora21, RHEL7, SLES12 and MCP8 OS. This causes 'make' fail as it tries to build for 's390' instead on 's390x'.

I am proposing the mentioned changes for fixing the issue.

Below is the output when I run the updated './configure' script:

bash-4.3# ./configure
{ 'target_defaults': { 'cflags': [],
                       'default_configuration': 'Release',
                       'defines': [],
                       'include_dirs': [],
                       'libraries': []},
  'variables': { 'clang': 0,
                 'gcc_version': 49,
                 'host_arch': 's390x',
                 'node_byteorder': 'big',
                 'node_install_npm': 'true',
                 'node_prefix': '',
                 'node_shared_cares': 'false',
                 'node_shared_http_parser': 'false',
                 'node_shared_libuv': 'false',
                 'node_shared_openssl': 'false',
                 'node_shared_v8': 'false',
                 'node_shared_zlib': 'false',
                 'node_tag': '',
                 'node_unsafe_optimizations': 0,
                 'node_use_dtrace': 'false',
                 'node_use_etw': 'false',
                 'node_use_openssl': 'true',
                 'node_use_perfctr': 'false',
                 'node_use_systemtap': 'false',
                 'openssl_no_asm': 0,
                 'python': '/usr/bin/python',
                 'target_arch': 's390x',
                 'v8_enable_gdbjit': 0,
                 'v8_no_strict_aliasing': 1,
                 'v8_use_snapshot': 'true',
                 'want_separate_host_toolset': 0}}
creating  ./config.gypi
creating  ./config.mk
bash-4.3#

Now it correctly identifies the host architecture for s390x.

Thanks.
Conflicts:
	configure
jBarz pushed a commit that referenced this issue Nov 7, 2016
@shahidhs @jBarz
Update configure
f211327 
After running './configure' on s390x architecture VM, I was getting following output:

bash-4.3# uname -rvmpio
3.10.0-229.1.2.el7.s390x #1 SMP Fri Mar 6 17:14:40 EST 2015 s390x s390x s390x GNU/Linux

bash-4.3# ./configure
{ 'target_defaults': { 'cflags': [],
                       'default_configuration': 'Release',
                       'defines': [],
                       'include_dirs': [],
                       'libraries': []},
  'variables': { 'clang': 0,
                 'gcc_version': 49,
                 'host_arch': 's390',
                 'node_byteorder': 'big',
                 'node_install_npm': 'true',
                 'node_prefix': '',
                 'node_shared_cares': 'false',
                 'node_shared_http_parser': 'false',
                 'node_shared_libuv': 'false',
                 'node_shared_openssl': 'false',
                 'node_shared_v8': 'false',
                 'node_shared_zlib': 'false',
                 'node_tag': '',
                 'node_unsafe_optimizations': 0,
                 'node_use_dtrace': 'false',
                 'node_use_etw': 'false',
                 'node_use_openssl': 'true',
                 'node_use_perfctr': 'false',
                 'node_use_systemtap': 'false',
                 'openssl_no_asm': 0,
                 'python': '/usr/bin/python',
                 'target_arch': 's390',
                 'v8_enable_gdbjit': 0,
                 'v8_no_strict_aliasing': 1,
                 'v8_use_snapshot': 'true',
                 'want_separate_host_toolset': 0}}
creating  ./config.gypi
creating  ./config.mk
bash-4.3#

As we could see, the configure script has returned me incorrect architecture i.e. 's390' instead of 's390x'. I got this behavior for Fedora21, RHEL7, SLES12 and MCP8 OS. This causes 'make' fail as it tries to build for 's390' instead on 's390x'.

I am proposing the mentioned changes for fixing the issue.

Below is the output when I run the updated './configure' script:

bash-4.3# ./configure
{ 'target_defaults': { 'cflags': [],
                       'default_configuration': 'Release',
                       'defines': [],
                       'include_dirs': [],
                       'libraries': []},
  'variables': { 'clang': 0,
                 'gcc_version': 49,
                 'host_arch': 's390x',
                 'node_byteorder': 'big',
                 'node_install_npm': 'true',
                 'node_prefix': '',
                 'node_shared_cares': 'false',
                 'node_shared_http_parser': 'false',
                 'node_shared_libuv': 'false',
                 'node_shared_openssl': 'false',
                 'node_shared_v8': 'false',
                 'node_shared_zlib': 'false',
                 'node_tag': '',
                 'node_unsafe_optimizations': 0,
                 'node_use_dtrace': 'false',
                 'node_use_etw': 'false',
                 'node_use_openssl': 'true',
                 'node_use_perfctr': 'false',
                 'node_use_systemtap': 'false',
                 'openssl_no_asm': 0,
                 'python': '/usr/bin/python',
                 'target_arch': 's390x',
                 'v8_enable_gdbjit': 0,
                 'v8_no_strict_aliasing': 1,
                 'v8_use_snapshot': 'true',
                 'want_separate_host_toolset': 0}}
creating  ./config.gypi
creating  ./config.mk
bash-4.3#

Now it correctly identifies the host architecture for s390x.

Thanks.
Conflicts:
	configure
jBarz pushed a commit that referenced this issue May 11, 2017
@isheludko @MylesBorins
deps: cherry-pick a814b8a from upstream V8
3fc6a22 
Original commit message:
  Merged: [heap] Clear recorded slots for inobject properties when migrating fast object to slow mode.

  Revision: a814b8aeaf2b56635054c96435972dce90576f62

  BUG=chromium:666046
  LOG=N
  NOTRY=true
  NOPRESUBMIT=true
  NOTREECHECKS=true
  R=ulan@chromium.org

  Review URL: https://codereview.chromium.org/2549803002 .

  Cr-Commit-Position: refs/branch-heads/5.5@{#60}
  Cr-Branched-From: 3cbd5838bd8376103daa45d69dade929ee4e0092-refs/heads/5.5.372@{#1}
  Cr-Branched-From: b3c8b0ce2c9af0528837d8309625118d4096553b-refs/heads/master@{#40015}

PR-URL: nodejs/node#10733
Reviewed-By: Reviewed-By: jasnell - James M Snell <jasnell@gmail.com>
Reviewed-By: mhdawson - Michael Dawson <michael_dawson@ca.ibm.com>
@arrathin arrathin mentioned this issue Dec 26, 2019
Open
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@andrewlow