Skip to content

Node.js 10.1.0 build broken on ppc64[le] #20642

Closed

Description

@sgallagher
  • Version: 10.1.0
  • Platform: Fedora Linux
  • Subsystem: Build system

Attempting to build 10.1.0 on ppc64 and ppc64le architectures results in a build failure. This failure was not present on 10.0.0.

My guess is that one of the assembler changes that came in between v8 6.6.346.27 and 6.6.346.24 broke something.

In file included from ../deps/v8/src/base/base-export.h:8:0,
                 from ../deps/v8/src/base/bits.h:11,
                 from ../deps/v8/src/ppc/macro-assembler-ppc.cc:10:
../deps/v8/src/ppc/macro-assembler-ppc.cc: In member function 'void v8::internal::TurboAssembler::Prologue()':
../deps/v8/src/ppc/macro-assembler-ppc.cc:853:15: error: expected primary-expression before '!=' token
   DCHECK(base != no_reg);
               ^
../deps/v8/include/v8config.h:346:54: note: in definition of macro 'V8_UNLIKELY'
 # define V8_UNLIKELY(condition) (__builtin_expect(!!(condition), 0))
                                                      ^~~~~~~~~
../deps/v8/src/base/logging.h:63:27: note: in expansion of macro 'DCHECK_WITH_MSG'
 #define DCHECK(condition) DCHECK_WITH_MSG(condition, #condition)
                           ^~~~~~~~~~~~~~~
../deps/v8/src/ppc/macro-assembler-ppc.cc:853:3: note: in expansion of macro 'DCHECK'
   DCHECK(base != no_reg);
   ^~~~~~

Activity

  1. added
    v8 engineIssues and PRs related to the V8 dependency.
    on May 9, 2018
  2. addaleax commented on May 9, 2018

    @addaleax
    Member

    This might have been “fixed” by v8/v8@7f90312 because that simply removes the DCHECK.

    @nodejs/v8

  3. added
    ppcIssues and PRs related to the Power architecture.
    on May 9, 2018
  4. sgallagher commented on May 9, 2018

    @sgallagher
    ContributorAuthor

    Yeah, that patch gets quite a bit further. However, it fails further on while trying to build the debugging node with:

      g++ -pthread -rdynamic -m64 -Wl,--whole-archive,/builddir/build/BUILD/node-v10.1.0/out/Release/obj.target/libnode.a -Wl,--no-whole-archive -Wl,-z,noexecstack -Wl,--whole-archive /builddir/build/BUILD/node-v10.1.0/out/Release/obj.target/deps/v8/gypfiles/libv8_base.a -Wl,--no-whole-archive -Wl,-z,relro  -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -o /builddir/build/BUILD/node-v10.1.0/out/Release/node -Wl,--start-group /builddir/build/BUILD/node-v10.1.0/out/Release/obj.target/node/src/node_main.o /builddir/build/BUILD/node-v10.1.0/out/Release/obj.target/libnode.a /builddir/build/BUILD/node-v10.1.0/out/Release/obj.target/deps/v8/gypfiles/libv8_libplatform.a /builddir/build/BUILD/node-v10.1.0/out/Release/obj.target/tools/icu/libicui18n.a /builddir/build/BUILD/node-v10.1.0/out/Release/obj.target/deps/cares/libcares.a /builddir/build/BUILD/node-v10.1.0/out/Release/obj.target/deps/v8/gypfiles/libv8_base.a /builddir/build/BUILD/node-v10.1.0/out/Release/obj.target/deps/v8/gypfiles/libv8_libbase.a /builddir/build/BUILD/node-v10.1.0/out/Release/obj.target/deps/v8/gypfiles/libv8_libsampler.a /builddir/build/BUILD/node-v10.1.0/out/Release/obj.target/tools/icu/libicuucx.a /builddir/build/BUILD/node-v10.1.0/out/Release/obj.target/tools/icu/libicudata.a /builddir/build/BUILD/node-v10.1.0/out/Release/obj.target/tools/icu/libicustubdata.a /builddir/build/BUILD/node-v10.1.0/out/Release/obj.target/deps/v8/gypfiles/libv8_snapshot.a -lz -lhttp_parser -luv -lnghttp2 -lcrypto -lssl -ldl -lrt -Wl,--end-group
      LD_LIBRARY_PATH=/builddir/build/BUILD/node-v10.1.0/out/Debug/lib.host:/builddir/build/BUILD/node-v10.1.0/out/Debug/lib.target:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH; cd ../deps/v8/gypfiles; mkdir -p /builddir/build/BUILD/node-v10.1.0/out/Debug/obj.target/v8_snapshot/geni; "/builddir/build/BUILD/node-v10.1.0/out/Debug/mksnapshot" --startup_src "/builddir/build/BUILD/node-v10.1.0/out/Debug/obj.target/v8_snapshot/geni/snapshot.cc" ""
    #
    # Fatal error in ../deps/v8/src/allocation.cc, line 146
    # Debug check failed: address == AlignedAddress(address, alignment) (0x1fafde041000 vs. 0x1fafde040000).
    #
    #
    #
    #FailureMessage Object: 0x7fffcec97d68
    ==== C stack trace ===============================
        /builddir/build/BUILD/node-v10.1.0/out/Debug/mksnapshot(v8::base::debug::StackTrace::StackTrace()+0x24) [0x1268e4704]
        /builddir/build/BUILD/node-v10.1.0/out/Debug/mksnapshot(+0x154fe14) [0x12654fe14]
        /builddir/build/BUILD/node-v10.1.0/out/Debug/mksnapshot(V8_Fatal(char const*, int, char const*, ...)+0x128) [0x126544458]
        /builddir/build/BUILD/node-v10.1.0/out/Debug/mksnapshot(+0x15444a8) [0x1265444a8]
        /builddir/build/BUILD/node-v10.1.0/out/Debug/mksnapshot(V8_Dcheck(char const*, int, char const*)+0x30) [0x1265444f0]
        /builddir/build/BUILD/node-v10.1.0/out/Debug/mksnapshot(v8::internal::AllocatePages(void*, unsigned long, unsigned long, v8::PageAllocator::Permission)+0x318) [0x125f10988]
        /builddir/build/BUILD/node-v10.1.0/out/Debug/mksnapshot(v8::internal::VirtualMemory::VirtualMemory(unsigned long, void*, unsigned long)+0x8c) [0x125f10bbc]
        /builddir/build/BUILD/node-v10.1.0/out/Debug/mksnapshot(v8::internal::AlignedAllocVirtualMemory(unsigned long, unsigned long, void*, v8::internal::VirtualMemory*)+0x40) [0x125f10d80]
        /builddir/build/BUILD/node-v10.1.0/out/Debug/mksnapshot(v8::internal::CodeRange::SetUp(unsigned long)+0xcc) [0x125a2f5ec]
        /builddir/build/BUILD/node-v10.1.0/out/Debug/mksnapshot(v8::internal::Heap::SetUp()+0xb4) [0x1259bd604]
        /builddir/build/BUILD/node-v10.1.0/out/Debug/mksnapshot(v8::internal::Isolate::Init(v8::internal::StartupDeserializer*)+0x5b8) [0x125a94298]
        /builddir/build/BUILD/node-v10.1.0/out/Debug/mksnapshot(v8::SnapshotCreator::SnapshotCreator(long const*, v8::StartupData*)+0x14c) [0x12561690c]
        /builddir/build/BUILD/node-v10.1.0/out/Debug/mksnapshot(v8::V8::CreateSnapshotDataBlob(char const*)+0x78) [0x1256895f8]
        /builddir/build/BUILD/node-v10.1.0/out/Debug/mksnapshot(main+0x15c) [0x12561320c]
        /lib64/libc.so.6(+0x24778) [0x7fffa3a94778]
        /lib64/libc.so.6(__libc_start_main+0xc4) [0x7fffa3a94984]
    /bin/sh: line 1: 29054 Trace/breakpoint trap   (core dumped) "/builddir/build/BUILD/node-v10.1.0/out/Debug/mksnapshot" --startup_src "/builddir/build/BUILD/node-v10.1.0/out/Debug/obj.target/v8_snapshot/geni/snapshot.cc" ""
    make[1]: *** [deps/v8/gypfiles/v8_snapshot.target.mk:13: /builddir/build/BUILD/node-v10.1.0/out/Debug/obj.target/v8_snapshot/geni/snapshot.cc] Error 133
    make: *** [Makefile:91: node_g] Error 2
    

    (This failure also occurs on s390x)

  5. bnoordhuis commented on May 10, 2018

    @bnoordhuis
    Member

    @nodejs/platform-ppc @nodejs/platform-s390

  6. john-yan commented on May 10, 2018

    @john-yan

    Hello, which v8 branch/hash are you using? Can V8 be built on your environment?

  7. mhdawson commented on May 11, 2018

    @mhdawson
    Member

    The other key question is which compiler level and binutils levels are you using? @jBarz would it be possible for you to find a fedora system to see if you can replicate with the required compiler level. Of note the compiler level requirement was increased for 10.x (actually it was increased for earlier release as well but we only move the community machines up for 10.x) but it may only be more recent levels of v8 that have introduced dependencies.

  8. sgallagher commented on May 11, 2018

    @sgallagher
    ContributorAuthor

    This specific one was run with GCC 8.1 and binutils 2.30.

    I can't build v8 separately from Node.js at the moment as I don't have any build scripts for it that I can use for our buildsystem (since I don't have direct access to the builders for those arches).

    @jBarz I can help you get access to https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers for a PPC64 or PPC64le machine (I'll get one of them updated to F28 if that's the approach we want to go).

    For the time being, I've just disabled the debug build on our packages on those arches; it'll have only the release binary node and not our debug-enabled version node_g.

  9. mhdawson commented on May 11, 2018

    @mhdawson
    Member

    Ok, those compiler/binutils levels are higher than the ones used in the community so we'd expect it to be ok. Thinking about it more I see its only the debug one that is failing and we don't build that in the community.

  10. jBarz commented on May 14, 2018

    @jBarz
    Contributor

    @sgallagher Can we get access to a ppc64le fedora?

  11. sgallagher commented on May 15, 2018

    @sgallagher
    ContributorAuthor

    @jBarz Yes, I've got someone working on getting you access to a public test machine. He will reply on this issue as soon as it's ready. Sorry for the delay.

  12. mhdawson commented on May 29, 2018

    @mhdawson
    Member
  13. sgallagher commented on May 29, 2018

    @sgallagher
    ContributorAuthor

    Pong. This isn’t forgotten, but it’s taking me longer than anticipated to get you access to a machine. I’m out of the office today, but I’ll look into things tomorrow. Apologies on the delay.

  14. sgallagher commented on May 29, 2018

    @sgallagher
    ContributorAuthor

    @mhdawson @jBarz If you could please create a Fedora account at https://admin.fedoraproject.org/accounts and sign the FPCA then I can give you access to one of our test machines. Please reply (or direct email me at sgallagh (at) redhat (dot) com) with the account(s) you created and I'll have them added to the ACL for the machine.

    (Note: the FPCA does not impact copyright ownership, it is just an assertion that if you make a contribution, you assert that you have the rights to make that contribution and that the contribution is being made under an acceptable open-source license).

  15. mhdawson commented on Jun 18, 2018

    @mhdawson
    Member

    @jBarz any update on this?

  16. 18 remaining items

  17. sgallagher commented on Nov 26, 2018

    @sgallagher
    ContributorAuthor

    @john-yan OK, once you have the SSH key uploaded, I'll get you access.

  18. john-yan commented on Nov 26, 2018

    @john-yan

    @sgallagher Thanks, Just uploaded ssh public key.

  19. sgallagher commented on Nov 26, 2018

    @sgallagher
    ContributorAuthor
  20. john-yan commented on Nov 26, 2018

    @john-yan

    @sgallagher Thanks, I will have a look.

  21. mhdawson commented on Dec 17, 2018

    @mhdawson
    Member

    @john-yan any update?

  22. miladfarca commented on Jan 28, 2019

    @miladfarca
    Contributor

    Applying 2 more patches to the above patches will fix the debug compiling, here is a diff:

    diff --git a/deps/v8/src/base/platform/platform-posix.cc b/deps/v8/src/base/platform/platform-posix.cc
    index f85f7fe942..e6ca0fe222 100644
    --- a/deps/v8/src/base/platform/platform-posix.cc
    +++ b/deps/v8/src/base/platform/platform-posix.cc
    @@ -244,11 +244,11 @@ void* OS::GetRandomMmapAddr() {
       // Use extra address space to isolate the mmap regions.
       raw_addr += uint64_t{0x400000000000};
     #elif V8_TARGET_BIG_ENDIAN
    -  // Big-endian Linux: 44 bits of virtual addressing.
    +  // Big-endian Linux: 42 bits of virtual addressing.
       raw_addr &= uint64_t{0x03FFFFFFF000};
     #else
    -  // Little-endian Linux: 48 bits of virtual addressing.
    -  raw_addr &= uint64_t{0x3FFFFFFFF000};
    +  // Little-endian Linux: 46 bits of virtual addressing.
    +  raw_addr &= uint64_t{0x3FFFFFFF0000};
     #endif
     #elif V8_TARGET_ARCH_MIPS64
       // We allocate code in 256 MB aligned segments because of optimizations using
    diff --git a/deps/v8/src/heap/store-buffer.cc b/deps/v8/src/heap/store-buffer.cc
    index 724edf5721..d48a471e52 100644
    --- a/deps/v8/src/heap/store-buffer.cc
    +++ b/deps/v8/src/heap/store-buffer.cc
    @@ -57,7 +57,7 @@ void StoreBuffer::SetUp() {
       }
     
       if (!reservation.SetPermissions(reinterpret_cast<Address>(start_[0]),
    -                                  kStoreBufferSize * kStoreBuffers,
    +                                  RoundUp(kStoreBufferSize * kStoreBuffers, CommitPageSize()),
                                       PageAllocator::kReadWrite)) {
         V8::FatalProcessOutOfMemory("StoreBuffer::SetUp");
       }
    diff --git a/deps/v8/src/ppc/macro-assembler-ppc.cc b/deps/v8/src/ppc/macro-assembler-ppc.cc
    index 68efa84c72..8105612064 100644
    --- a/deps/v8/src/ppc/macro-assembler-ppc.cc
    +++ b/deps/v8/src/ppc/macro-assembler-ppc.cc
    @@ -168,7 +168,7 @@ void TurboAssembler::Call(Register target) {
     }
     
     void MacroAssembler::CallJSEntry(Register target) {
    -  DCHECK(target == ip);
    +  DCHECK(target == r5);
       Call(target);
     }
     
    @@ -850,7 +850,6 @@ void TurboAssembler::StubPrologue(StackFrame::Type type) {
     }
     
     void TurboAssembler::Prologue() {
    -  DCHECK(base != no_reg);
       PushStandardFrame(r4);
       if (FLAG_enable_embedded_constant_pool) {
         // base contains prologue address
    
    
  23. mhdawson commented on Jan 28, 2019

    @mhdawson
    Member

    @miladfarca thanks for the update :). I guess the next steps are potentially getting into V8 master if the problem still exists there as a pre-req for floating in Node.js.

  24. miladfarca commented on Jan 29, 2019

    @miladfarca
    Contributor

    @mhdawson no problem, master already includes these fixes, either with the exact code or a modified version past this branch, I have confirmed this by looking at the v8 master as well v8 in nodejs master. I have also built the latest nodejs on fedora/ppc64 and it builds with no errors.

    I am going to work on backporting this fix to an abandoned branch of v8 in nodejs 10.1.0

  25. miladfarca commented on Feb 1, 2019

    @miladfarca
    Contributor

    PR submitted for backport to v10.x

    #25827

  26. mhdawson commented on Feb 1, 2019

    @mhdawson
    Member

    @miladfarca thanks for the update and the PRs :)

  27. miladfarca commented on Feb 1, 2019

    @miladfarca
    Contributor

    @mhdawson Not a problem.

  28. mhdawson commented on Mar 1, 2019

    @mhdawson
    Member

    Looks like PR landed so we just need to wait for the next v10.x release :)

  29. BethGriggs commented on Mar 15, 2019

    @BethGriggs
    Member

    @sgallagher, #25827 landed and was released in v10.15.3, so I believe this is now fixed. Thanks @miladfarca

  30. sgallagher commented on Mar 15, 2019

    @sgallagher
    ContributorAuthor

    I can confirm that this worked in my Fedora builds. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    ppcIssues and PRs related to the Power architecture.v8 engineIssues and PRs related to the V8 dependency.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions