Puh, that's a tricky bug. It happens because gdb sets breakpoints by
replacing individual instructions with the "int 3" instruction. When
executed, this will cause a debug trap which gdb catches.
The check fails because we check that the snapshot is correct by
recomputing a hash of its content. Now the builtins are part of the
snapshot, and since gdb replaced one byte, the hash changed.
This can be seen in gdb:
#1 0x00007f4afe235b42 in v8::internal::Isolate::SetEmbeddedBlob
(this=0x5559ef749be0, blob=0x7f4afeb927a0 <v8_Default_embedded_blob_data_>
"\022\026\376uA\344zd", blob_size=5765600) at ../../src/isolate.cc:198
198 CHECK_EQ(d.Hash(), d.CreateHash());
(gdb) p d
$1 = {static kTableSize = 1499, data_ = 0x7f4afeb927a0
<v8_Default_embedded_blob_data_> "\022\026\376uA\344zd", size_ = 5765600}
(gdb) info break
[...]
3 breakpoint keep y 0x00007f4afee40404 <Builtins_StringPrototypeReplace+4>
Note that the address of the breakpoint is within [d.data_, d.data_ +
d.size_].
So this is not really a bug, even though we should check whether there is a
way to detect that we are running in a debugger, and skip the hash check
then.
For now you should ensure that you only set breakpoints (on builtins)
*after* the isolate is initialized. Or just remove the CHECK for now.
Hope that helps,
Clemens
On Fri, Dec 14, 2018 at 5:47 PM <[email protected]> wrote:
> Thanks Rodolph,
>
> I was actually looked at it a little bit and fixed all the compilation
> problem. However, it failed during runtime. Then I tried to see if X86 was
> successful, and it failed as well.
>
> I was under the impression that X86 was all good. Here's how it failed on
> tip. (I have not tried branches)
> gdb --args ./d8 --gdbjit foo.js
>
> (gdb) b Builtins_StringPrototypeReplace
> Breakpoint 2 at 0x5555567b7bc4
> (gdb) r
> The program being debugged has been started already.
> Start it from the beginning? (y or n) y
> Starting program: /work/sirish.pande/v8/v8/out/x64.master.debug.gdbjit/d8
> --gdbjit foo.js
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> [New Thread 0x7ffff662d700 (LWP 23951)]
> [New Thread 0x7ffff5e2c700 (LWP 23952)]
> [New Thread 0x7ffff562b700 (LWP 23953)]
> [New Thread 0x7ffff4e2a700 (LWP 23954)]
> [New Thread 0x7ffff4629700 (LWP 23955)]
> [New Thread 0x7ffff3e28700 (LWP 23956)]
> [New Thread 0x7ffff3627700 (LWP 23957)]
> [New Thread 0x7ffff2e26700 (LWP 23958)]
>
>
> #
> # Fatal error in ../../src/isolate.cc, line 198
> # Check failed: d.Hash() == d.CreateHash() (18072318529312869522 vs.
> 8652045362104995461).
> #
> #
> #
> #FailureMessage Object: 0x7fffffffc1f0
> ==== C stack trace ===============================
>
> /work/sirish.pande/v8/v8/out/x64.master.debug.gdbjit/d8(+0x161bcf3)
> [0x555556b6fcf3]
> /work/sirish.pande/v8/v8/out/x64.master.debug.gdbjit/d8(+0x161b2bb)
> [0x555556b6f2bb]
> /work/sirish.pande/v8/v8/out/x64.master.debug.gdbjit/d8(+0x1613678)
> [0x555556b67678]
> /work/sirish.pande/v8/v8/out/x64.master.debug.gdbjit/d8(+0xa36e12)
> [0x555555f8ae12]
> /work/sirish.pande/v8/v8/out/x64.master.debug.gdbjit/d8(+0xa36c54)
> [0x555555f8ac54]
> /work/sirish.pande/v8/v8/out/x64.master.debug.gdbjit/d8(+0xa35dd8)
> [0x555555f89dd8]
> /work/sirish.pande/v8/v8/out/x64.master.debug.gdbjit/d8(+0x3faef1)
> [0x55555594eef1]
> /work/sirish.pande/v8/v8/out/x64.master.debug.gdbjit/d8(+0x3a9214)
> [0x5555558fd214]
> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)
> [0x7ffff7028b97]
> /work/sirish.pande/v8/v8/out/x64.master.debug.gdbjit/d8(_start+0x2a)
> [0x5555558eb02a]
>
> Thread 1 "d8" received signal SIGILL, Illegal instruction.
> v8::base::OS::Abort () at ../../src/base/platform/platform-posix.cc:401
> 401 V8_IMMEDIATE_CRASH();
> (gdb) i b
> Num Type Disp Enb Address What
> 1 breakpoint keep y 0x0000555555f8c3e7 in
> v8::internal::Isolate::Init(v8::internal::StartupDeserializer*) at
> ../../src/isolate.cc:3180
> 2 breakpoint keep y 0x00005555567b7bc4
> <Builtins_StringPrototypeReplace+4>
>
> Should we open bug for this one?
>
> Sirish
>
> On Thursday, December 13, 2018 at 11:13:39 AM UTC-6, Rodolph Perfetta
> wrote:
>
>> You are right the arm/arm64 gdb-jit support is not complete, so it is
>> more a feature request. I am happy to help with review if you submit a
>> patch.
>>
>> Cheers,
>> Rodolph.
>>
>> On Wed, 12 Dec 2018 at 21:36, <[email protected]> wrote:
>>
>>> Thanks Rodolph. When I try to build with v8_enable_gdbjit=true,
>>> unfortunately, I run into compilation errors of gdb-jit for ARM64. Snippet
>>> below shows the way try to build. It shows that I am using 7.1.1 - however,
>>> it's the same problem with tip/master as well. Should I open a bug for this
>>> one?
>>>
>>> cc01:v8:[7.1.1]>gn gen --args="target_cpu=\"arm64\"
>>> is_component_build=false v8_enable_gdbjit=true" out/7.1.1.debug.gdbjit
>>> Done. Made 159 targets from 80 files in 346ms
>>> cc01:v8:[7.1.1]>autoninja -C out/7.1.1.debug.gdbjit d8
>>> ninja -C out/7.1.1.debug.gdbjit d8 -l 128
>>> ninja: Entering directory `out/7.1.1.debug.gdbjit'
>>> [1340/2173] CXX obj/v8_base/gdb-jit.o
>>> FAILED: obj/v8_base/gdb-jit.o
>>> ../../third_party/llvm-build/Release+Asserts/bin/clang++ -MMD -MF
>>> obj/v8_base/gdb-jit.o.d -DV8_DEPRECATION_WARNINGS -DUSE_UDEV -DUSE_AURA=1
>>> -DUSE_GLIB=1 -DUSE_NSS_CERTS=1 -DUSE_X11=1 -DNO_TCMALLOC
>>> -DFULL_SAFE_BROWSING -DSAFE_BROWSING_CSD -DSAFE_BROWSING_DB_LOCAL
>>> -DCHROMIUM_BUILD -DFIELDTRIAL_TESTING_ENABLED -D_FILE_OFFSET_BITS=64
>>> -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_GNU_SOURCE
>>> -DCR_CLANG_REVISION=\"338452-1\" -D__STDC_CONSTANT_MACROS
>>> -D__STDC_FORMAT_MACROS -D_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS
>>> -D_LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS -DCR_LIBCXX_REVISION=332543
>>> -DCR_LIBCXXABI_REVISION=331450
>>> -DCR_SYSROOT_HASH=c68b2062879db201c4047d03c016227d3d1e7b35 -D_DEBUG
>>> -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DWTF_USE_DYNAMIC_ANNOTATIONS=1
>>> -DENABLE_DISASSEMBLER -DV8_TYPED_ARRAY_MAX_SIZE_IN_HEAP=64
>>> -DENABLE_GDB_JIT_INTERFACE -DENABLE_MINOR_MC -DOBJECT_PRINT -DVERIFY_HEAP
>>> -DV8_TRACE_MAPS -DV8_ENABLE_ALLOCATION_TIMEOUT -DV8_ENABLE_FORCE_SLOW_PATH
>>> -DV8_ENABLE_CHECKS -DV8_DEPRECATION_WARNINGS
>>> -DV8_IMMINENT_DEPRECATION_WARNINGS -DV8_INTL_SUPPORT
>>> -DENABLE_HANDLE_ZAPPING -DV8_USE_SNAPSHOT -DV8_USE_EXTERNAL_STARTUP_DATA
>>> -DV8_CONCURRENT_MARKING -DV8_CHECK_MICROTASKS_SCOPES_CONSISTENCY
>>> -DV8_EMBEDDED_BUILTINS -DV8_TARGET_ARCH_ARM64 -DDEBUG
>>> -DU_USING_ICU_NAMESPACE=0 -DU_ENABLE_DYLOAD=0 -DU_STATIC_IMPLEMENTATION
>>> -DICU_UTIL_DATA_IMPL=ICU_UTIL_DATA_FILE -DUCHAR_TYPE=uint16_t -I../.. -Igen
>>> -I../.. -Igen -I../../third_party/icu/source/common
>>> -I../../third_party/icu/source/i18n -I../../include -fno-strict-aliasing
>>> --param=ssp-buffer-size=4 -fstack-protector -Wno-builtin-macro-redefined
>>> -D__DATE__= -D__TIME__= -D__TIMESTAMP__= -funwind-tables -fPIC -pthread
>>> -fcolor-diagnostics -fmerge-all-constants -no-canonical-prefixes
>>> -fcomplete-member-pointers --target=aarch64-linux-gnu -Wall -Werror -Wextra
>>> -Wimplicit-fallthrough -Wthread-safety -Wno-missing-field-initializers
>>> -Wno-unused-parameter -Wno-c++11-narrowing -Wno-covered-switch-default
>>> -Wno-unneeded-internal-declaration -Wno-undefined-var-template
>>> -Wno-nonportable-include-path -Wno-user-defined-warnings
>>> -Wno-unused-lambda-capture -Wno-null-pointer-arithmetic
>>> -Wno-enum-compare-switch -Wno-ignored-pragma-optimize
>>> -fno-omit-frame-pointer -g2 -fvisibility=hidden -Wheader-hygiene
>>> -Wstring-conversion -Wtautological-overlap-compare
>>> -Wmissing-field-initializers -Winconsistent-missing-override
>>> -Wunreachable-code -Wshorten-64-to-32 -O3 -fno-ident -fdata-sections
>>> -ffunction-sections -Wno-undefined-bool-conversion
>>> -Wno-tautological-undefined-compare -std=c++14 -fno-exceptions -fno-rtti
>>> -nostdinc++ -isystem../../buildtools/third_party/libc++/trunk/include
>>> -isystem../../buildtools/third_party/libc++abi/trunk/include
>>> --sysroot=../../build/linux/debian_sid_arm64-sysroot
>>> -fvisibility-inlines-hidden -c ../../src/gdb-jit.cc -o obj/v8_base/gdb-jit.o
>>> ../../src/gdb-jit.cc:668:2: error: Unsupported target architecture.
>>> #error Unsupported target architecture.
>>> ^
>>> ../../src/gdb-jit.cc:697:2: error: Unsupported target architecture.
>>> #error Unsupported target architecture.
>>> ^
>>> ../../src/gdb-jit.cc:670:27: error: use of undeclared identifier 'ident'
>>> memcpy(header->ident, ident, 16);
>>> ^
>>> ../../src/gdb-jit.cc:838:27: error: use of undeclared identifier
>>> 'SerializedLayout'
>>> void Write(Writer::Slot<SerializedLayout> s, ELFStringTable* t) const {
>>> ^
>>> ../../src/gdb-jit.cc:912:49: error: no member named 'SerializedLayout'
>>> in 'v8::internal::GDBJITInterface::ELFSymbol'
>>> Writer::Slot<ELFSymbol::SerializedLayout> dst,
>>> ~~~~~~~~~~~^
>>> ../../src/gdb-jit.cc:870:29: error: no member named 'SerializedLayout'
>>> in 'v8::internal::GDBJITInterface::ELFSymbol'
>>> Writer::Slot<ELFSymbol::SerializedLayout> symbols =
>>> ~~~~~~~~~~~^
>>> ../../src/gdb-jit.cc:870:47: error: C++ requires a type specifier for
>>> all declarations
>>> Writer::Slot<ELFSymbol::SerializedLayout> symbols =
>>> ^
>>> ../../src/gdb-jit.cc:871:39: error: no member named 'SerializedLayout'
>>> in 'v8::internal::GDBJITInterface::ELFSymbol'
>>> w->CreateSlotsHere<ELFSymbol::SerializedLayout>(
>>> ~~~~~~~~~~~^
>>> ../../src/gdb-jit.cc:871:56: error: expected unqualified-id
>>> w->CreateSlotsHere<ELFSymbol::SerializedLayout>(
>>> ^
>>> ../../src/gdb-jit.cc:880:34: error: no member named 'SerializedLayout'
>>> in 'v8::internal::GDBJITInterface::ELFSymbol'
>>> symbols.at(0).set(ELFSymbol::SerializedLayout(0,
>>> ~~~~~~~~~~~^
>>> ../../src/gdb-jit.cc:907:44: error: no member named 'SerializedLayout'
>>> in 'v8::internal::GDBJITInterface::ELFSymbol'
>>> header->entry_size = sizeof(ELFSymbol::SerializedLayout);
>>> ~~~~~~~~~~~^
>>> ../../src/gdb-jit.cc:1160:2: error: Unsupported target architecture.
>>> #error Unsupported target architecture.
>>> ^
>>> 12 errors generated.
>>> [1469/2173] CXX obj/v8_base/code-stub-assembler.o
>>> ninja: build stopped: subcommand failed.
>>>
>>>
>>> On Wednesday, December 12, 2018 at 12:08:13 PM UTC-6, Rodolph Perfetta
>>> wrote:
>>>>
>>>> Just checking, when building v8, you did enable gdbjit?
>>>> v8_enable_gdbjit=true in gn args. The blog you pointed to is a bit out of
>>>> date.
>>>>
>>>>
>>>>
>>>> On Wed, 12 Dec 2018 at 07:49, Jakob Gruber <[email protected]> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Tue, Dec 11, 2018 at 11:45 PM <[email protected]> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> In some of the profiles that I have been looking at CheckObjectType
>>>>>> comes out are pretty hot. I noticed that this is called multiple times
>>>>>> from
>>>>>> various builtins or other jitted code. I wanted to know where in jitted
>>>>>> code or builtins is this call coming from.
>>>>>>
>>>>>
>>>>> This doesn't answer your main question, but CheckObjectType calls only
>>>>> occur in debug mode and are emitted when creating TNodes (typed nodes),
>>>>> see
>>>>> here
>>>>> <https://cs.chromium.org/chromium/src/v8/src/compiler/code-assembler.h?l=703&rcl=72448bedcf497b26a742fe96bb1d387d7421d10d>
>>>>> .
>>>>>
>>>>>
>>>>>>
>>>>>> Unfortunately, I can not step into jitted code while running d8 with
>>>>>> gdb. I found the following link which talks about gdb-jit
>>>>>> https://v8.dev/docs/gdb-jit. It mostly talks about ia32.
>>>>>>
>>>>>> I was wondering if anyone has looked at running GDB on d8 on ARM64?
>>>>>> Is it possible to break in the native code at all in ARM64?
>>>>>>
>>>>>> --
>>>>> --
>>>>> v8-dev mailing list
>>>>> [email protected]
>>>>> http://groups.google.com/group/v8-dev
>>>>> ---
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "v8-dev" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to [email protected].
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>> --
>>> --
>>> v8-dev mailing list
>>> [email protected]
>>> http://groups.google.com/group/v8-dev
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "v8-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> --
> v8-dev mailing list
> [email protected]
> http://groups.google.com/group/v8-dev
> ---
> You received this message because you are subscribed to the Google Groups
> "v8-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
>
--
Clemens Hammacher
Software Engineer
[email protected]
Google Germany GmbH
Erika-Mann-Straße 33
80636 München
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten
haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter,
löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen,
dass die E-Mail an die falsche Person gesendet wurde.
This e-mail is confidential. If you received this communication by mistake,
please don't forward it to anyone else, please erase all copies and
attachments, and please let me know that it has gone to the wrong person.
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups
"v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
