[v8-users] Re: using custom toolchain for V8 builds

[madana gopal]

Hi Team,

Please share if we have any way to point to custom toolchain for arm and 
build.

Thanks.

Regards,
Madan

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [v8-users] Each bytecode is an object?

[Jakob Kummerow]

Everything on the heap is a heap object ;-)

I guess the term "bytecode" is slightly overloaded. If you mean "the
bytecode of a function", i.e. the entire bytecode representation of that
function, then yes, that is indeed stored as an object on the heap
(where/how else would it be stored?); and "Bytecode" is the C++ class that
describes the layout of that object.

If you mean "each bytecode" in the sense of "each bytecode instruction,
e.g. LdaSmi", then no: they are not individual objects. They are raw
numbers encoding the respective bytecode instruction.

In short: 1 function -> 1 AST (with many AST nodes in it) -> 1 bytecode
object (with many bytecode instructions in it).

Note that heap objects are not objects of the respective class in the usual
C++ sense -- again this is the same for Bytecode and all other heap objects.


On Thu, Nov 15, 2018 at 11:27 AM TLim  wrote:

> I'm trying to get the idea of how ignition generates the bytecode from the
> AST and handles it straight.
>
> My understanding is that when the Ignition walks through the AST from the
> parser, it generates bytecodes.
> Then, how it generates is that each bytecode is actually an object of
> bytecode class.
>
> Probably how it gets generated and handled is way more complicated, but I
> simply want to get the idea straight first that the bytecode is actually a
> class object.
>
> Thank you!
>
> --
> --
> v8-users mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users
> ---
> You received this message because you are subscribed to the Google Groups
> "v8-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to v8-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Each bytecode is an object?

[TLim]

I'm trying to get the idea of how ignition generates the bytecode from the 
AST and handles it straight.

My understanding is that when the Ignition walks through the AST from the 
parser, it generates bytecodes.
Then, how it generates is that each bytecode is actually an object of 
bytecode class.

Probably how it gets generated and handled is way more complicated, but I 
simply want to get the idea straight first that the bytecode is actually a 
class object.

Thank you!

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Re: ChromeDevTools connected to Inspector, but error responses... missing native JS functions?

[@soylentgraham]

Ah that sounds more like the proper way to do it :)
I've not tried interrupts yet, so I'm no use here :)

On Wednesday, 14 November 2018 17:45:03 UTC, Konrad Piascik wrote:
>
> I have attached to node with the program executing in the middle of a 
> while/busy loop.
> I think I found what node is doing. 
>
> https://github.com/v8/v8/blob/96a039aab14b71069e88c4c04543e6bc9514a0d6/include/v8.h#L7969
>
> void v8::Isolate::RequestInterrupt(InterruptCallback callback, void* data);
> This function stops JavaScript execution and might be the answer to my 
> problem.  The callback is called on the isolate's thread.
>
> Cheers,
> Konrad
>
> On Wednesday, November 14, 2018 at 10:52:53 AM UTC-5, @soylentgraham wrote:
>>
>> Going off topic now, but can you attach & break into node.js whilst it's 
>> in a big blocking function? 
>> Or can you only break if you've previously attached? (I've only done 
>> light, very-async stuff in node)
>>
>> In long-running funcs (well, accidental massive loops) in chrome I find I 
>> struggle to break, so I kinda thought this was how it was, but maybe I'm 
>> wrong :)
>>
>>
>> On Wednesday, 14 November 2018 13:55:34 UTC, Konrad Piascik wrote:
>>>
>>> Yeah I can't make any assumptions or impose any requirements about what 
>>> the javascript to be executed will look like.
>>> It must be possible since Node.js already does this for long running 
>>> JavaScript.
>>>
>>> Thanks for the suggestions and quick responses
>>>
>>> -Konrad
>>>
>>> On Wednesday, November 14, 2018 at 7:53:57 AM UTC-5, @soylentgraham 
>>> wrote:

 The only way I could interrupt long runs of javascript, assuming you 
 can't break it yourself into asynchronous code (via promises/await, this 
 is 
 the nicest approach IMO me), is adding a yield function to let the event 
 loop run (I have other multithread-y reasons for this too, but letting 
 external actions run is one)

 But if you can't add code at all, you are probably stuck (afaik, 
 there's no real interrupting, because you're basically calling one big 
 RunJavascript() func on your thread :)

 In case it's useful, this is the C++ side, (and I call yield() in JS to 
 let other threads do JS calls, and let the debugger interrupt)


 void TV8Container::Yield(size_t SleepMilliseconds)

 {

 // gr: temporary unlock, but need to exit too

 {

 mIsolate->Exit();

 v8::Unlocker unlocker(mIsolate);

 // isolate unlock for a moment, let another thread jump in and run 
 stuff

 auto ms = std::chrono::milliseconds(SleepMilliseconds);

 std::this_thread::sleep_for( ms );

 }

 // re-enter after unlocker has gone out of scope

 mIsolate->Enter();

 }


 On Tuesday, 13 November 2018 21:06:59 UTC, Konrad Piascik wrote:
>
> Hi @soylentgraham,
>
> I'm trying to replicate what you're doing as well but am running into 
> some other problems.  The most notable of which is that my websocket is 
> on 
> a different thread than my isolate creation.
> I see from your solution that you're adding the frontend messages to a 
> queue and looking through them in your event loop.  My problem is that I 
> have long running javascript that is not intended to exit/return until 
> the 
> program stops.  Do you have any suggestions/ideas?
>
> Thanks,
> Konrad
>   
>
> On Tuesday, September 18, 2018 at 10:49:43 AM UTC-4, @soylentgraham 
> wrote:
>>
>> YetAnotherUpdate
>>
>> After some more digging, I found the issue I have is identified node 
>> and chromium too... 
>>
>> https://github.com/nodejs/node/commit/b1e26128f317a6f5a5808a0a727e98f80f088b84
>>
>> So, it looks like the default v8 [platform] isn't chrome-dev-tools 
>> compatible.
>> Ibon's case worked as it has a specific Android platform 
>> implementation. Chromium and Node also have their own platform.
>>
>> So, I made the most basic platform proxy possible to work around it...
>>
>> https://github.com/SoylentGraham/V8InspectorMinimal/blob/master/src/TV8Platform.h
>>
>> And it works!
>> I can now modify code on the fly, execute from the console.
>> I can't seem to debug, and pressing pause-execution a few times gives 
>> me a new assert, but the higher level code is a bit of a mess at this 
>> point, so I'm probably implementing something wrong...
>>
>> Still, if anyone else ever finds this problem... V8 alone cannot be 
>> used with chrome dev tools. (as of 7.1.0.0  
>>
>> 4544e18b0c3845a9fca422cf0903df4803343cf1)
>>
>> On Friday, 14 September 2018 11:44:33 UTC+1, @soylentgraham wrote:
>>>
>>> So the core of my issue at the moment, is this assert (UNIMPLEMENTED)
>>>
>>> void 
>>> DefaultWorkerThreadsTaskRunner::PostDelayedTask(std::unique_ptr 
>>> 

[v8-users] v8 linker for android build on Mac is not support ?

[wjxfhxy]

I'm building on MacOSX 10.14 for Android and  fixed third_party/android_ndk 
support mac , but it still error. Why? Is it v8 not support linker on mac?


It look like about c++ error


the error detail :



FAILED: obj/torque_base/csa-generator.o 

../../third_party/llvm-build/Release+Asserts/bin/clang++ -MMD -MF 
obj/torque_base/csa-generator.o.d -DV8_DEPRECATION_WARNINGS -DNO_TCMALLOC 
-DSAFE_BROWSING_DB_REMOTE -DCHROMIUM_BUILD -DFIELDTRIAL_TESTING_ENABLED 
-D_GNU_SOURCE -DANDROID -DHAVE_SYS_UIO_H -DANDROID_NDK_VERSION_ROLL=r16_1 
-DCR_CLANG_REVISION=\"346388-1\" -D__STDC_CONSTANT_MACROS 
-D__STDC_FORMAT_MACROS -D_FORTIFY_SOURCE=2 -D__GNU_SOURCE=1 
-DCHROMIUM_CXX_TWEAK_INLINES -DNDEBUG -DNVALGRIND 
-DDYNAMIC_ANNOTATIONS_ENABLED=0 -DV8_TYPED_ARRAY_MAX_SIZE_IN_HEAP=64 
-DENABLE_MINOR_MC -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_EMBEDDED_BUILTINS 
-DV8_EMBEDDED_BYTECODE_HANDLERS -DV8_TARGET_ARCH_ARM 
-DCAN_USE_ARMV7_INSTRUCTIONS -DCAN_USE_VFP3_INSTRUCTIONS 
-DCAN_USE_VFP32DREGS -DCAN_USE_NEON -DV8_ANDROID_LOG_STDOUT -I../.. -Igen 
-I../.. -Igen -fno-strict-aliasing --param=ssp-buffer-size=4 
-fstack-protector -Wno-builtin-macro-redefined -D__DATE__= -D__TIME__= 
-D__TIMESTAMP__= -funwind-tables -fPIC -fcolor-diagnostics 
-fmerge-all-constants -Xclang -mllvm -Xclang 
-instcombine-lower-dbg-declare=0 -no-canonical-prefixes -ffunction-sections 
-fno-short-enums --target=arm-linux-androideabi 
-isystem../../third_party/android_ndk/sysroot/usr/include/arm-linux-androideabi 
-D__ANDROID_API__=16 -DHAVE_PTHREAD_COND_TIMEDWAIT_MONOTONIC=1 
-march=armv7-a -mfloat-abi=softfp -mtune=generic-armv7-a -mfpu=neon -mthumb 
-Wall -Werror -Wextra -Wimplicit-fallthrough -Wthread-safety 
-Wno-missing-field-initializers -Wno-unused-parameter -Wno-c++11-narrowing 
-Wno-unneeded-internal-declaration -Wno-undefined-var-template 
-Wno-null-pointer-arithmetic -Wno-ignored-pragma-optimize 
-Wno-defaulted-function-deleted -fomit-frame-pointer -gdwarf-3 -g1 
-fdebug-info-for-profiling -fvisibility=hidden -Wheader-hygiene 
-Wstring-conversion -Wtautological-overlap-compare -Wexit-time-destructors 
-Wmissing-field-initializers -Winconsistent-missing-override 
-Wunreachable-code -O2 -fno-ident -fdata-sections -ffunction-sections 
-std=c++14 -fno-exceptions -fno-rtti 
--sysroot=../../third_party/android_ndk/sysroot 
-isystem../../third_party/android_ndk/sources/cxx-stl/llvm-libc++/include 
-isystem../../third_party/android_ndk/sources/cxx-stl/llvm-libc++abi/include 
-isystem../../third_party/android_ndk/sources/android/support/include 
-fvisibility-inlines-hidden -c ../../src/torque/csa-generator.cc -o 
obj/torque_base/csa-generator.o

In file included from ../../src/torque/csa-generator.cc:5:

In file included from ../../src/torque/csa-generator.h:8:

In file included from 
../../third_party/android_ndk/sources/cxx-stl/llvm-libc++/include/iostream:38:

In file included from 
../../third_party/android_ndk/sources/cxx-stl/llvm-libc++/include/ios:215:

In file included from 
../../third_party/android_ndk/sources/cxx-stl/llvm-libc++/include/iosfwd:90:

In file included from 
../../third_party/android_ndk/sources/cxx-stl/llvm-libc++/include/wchar.h:119:

../../third_party/android_ndk/sources/android/support/include/wchar.h:37:14: 
error: unknown type name 'FILE'

int vfwscanf(FILE*, const wchar_t*, va_list);

 ^

../../third_party/android_ndk/sources/android/support/include/wchar.h:37:37: 
error: unknown type name 'va_list'

int vfwscanf(FILE*, const wchar_t*, va_list);

^

../../third_party/android_ndk/sources/android/support/include/wchar.h:38:46: 
error: unknown type name 'va_list'

int vswscanf(const wchar_t*, const wchar_t*, va_list);

 ^

../../third_party/android_ndk/sources/android/support/include/wchar.h:39:29: 
error: unknown type name 'va_list'

int vwscanf(const wchar_t*, va_list);

^

../../third_party/android_ndk/sources/android/support/include/wchar.h:40:1: 
error: unknown type name 'size_t'

size_t mbsnrtowcs(wchar_t*, const char**, size_t, size_t, mbstate_t*);

^

../../third_party/android_ndk/sources/android/support/include/wchar.h:40:43: 
error: C++ requires a type specifier for all declarations

size_t mbsnrtowcs(wchar_t*, const char**, size_t, size_t, mbstate_t*);

  ^

../../third_party/android_ndk/sources/android/support/include/wchar.h:40:51: 
error: C++ requires a type specifier for all declarations

size_t mbsnrtowcs(wchar_t*, const char**, size_t, size_t, mbstate_t*);

  ^

../../third_party/android_ndk/sources/android/support/include/wchar.h:40:51: 
error: redefinition of parameter 'size_t'

../../third_party/android_ndk/sources/android/support/include/wchar.h:40:43: 

[v8-users] Re: How to rescue issues caused by v8::Isolate termination

[Kentaro Hara]

>
> I found that at the only place Isolate::TerminateExecution is called
> 
>  from
> blink, V8 is not even running. That would mean that we don't have to worry
> about any of this?


At that place the main thread (which is not running V8) is calling
TerminateExecution to terminate a running worker thread. The concern is on
the worker thread.


On Thu, Nov 15, 2018 at 6:51 PM Yang Guo  wrote:

> Hi,
>
> I found that at the only place Isolate::TerminateExecution is called
> 
>  from
> blink, V8 is not even running. That would mean that we don't have to worry
> about any of this?
>
> Cheers,
>
> Yang
>
> On Wed, Nov 14, 2018 at 10:00 AM Yang Guo  wrote:
>
>> I filed a bug for the slightly counter-intuitive behavior I mentioned:
>> https://bugs.chromium.org/p/v8/issues/detail?id=8455
>>
>> Cheers,
>>
>> Yang
>>
>> On Wed, Nov 14, 2018 at 9:01 AM Yang Guo  wrote:
>>
>>> When you terminate execution in V8, we abort execution until the
>>> bottom-most call into V8. If you have re-entries into V8, V8 always returns
>>> empty results until the bottom-most call into V8. On the Blink side on the
>>> stack of the re-entries, you can try to call into V8 before returning, but
>>> that will simply return empty results. v8::TryCatch scopes along the way
>>> will return true for v8::TryCatch::HasCaught and
>>> v8::TryCatch::HasTerminated. Isolate::IsExecutionTerminating returns true.
>>>
>>> As soon as we reach the bottom-most call, we return with an empty value
>>> as well. The v8::TryCatch scope around that will return true for
>>> v8::TryCatch::HasCaught and v8::TryCatch::HasTerminated, but
>>> Isolate::IsExecutionTerminating will return false (even if you are still
>>> inside this outer-most v8::TryCatch scope), because you can safely call
>>> into V8 again, from here on. I actually find this a bit counter-intuitive,
>>> and it might be better to have Isolate::IsExecutionTerminating return true,
>>> until we leave the outer-most v8::TryCatch. Though implementing that seems
>>> a bit annoying.
>>>
>>> So what you are observing is that you have a non-reentry call to execute
>>> the worker. That terminates, and you then have another non-reentry call.
>>> That is working as intended though. Once you have left V8 through
>>> termination across all re-entries, the isolate is good to be re-used again.
>>> I think the correct way to fix your issue is to, at non-reentry calls, 
>>> *always
>>> check for v8::TryCatch::HasTerminated, and use that to guide the following
>>> control flow*.
>>>
>>> To answer your questions:
>>>
 1. What happens if the isolate is forcibly terminated (from another
 thread) while running a script? Will an exception be thrown? Is a
 v8::TryCatch catches the exception?
>>>
>>> Internally we throw a special exception that cannot be caught by
>>> javascript. This exception causes execution to abort until we arrive at the
>>> first (non-reentry) call into V8.
>>>
>>> 2. What happens if we try to run a script when the isolate has already
 been terminated?
>>>
>>> If you completely exited V8 back to the first non-reentry call, you can
>>> safely use the isolate again.
>>>
>>> 3. What happens if v8 calls blink code, the isolate is forcibly
 terminated and then the control is back to v8?
>>>
>>> The termination exception is propagated back to V8, causes the current
>>> execution to abort, so that we return an empty value to blink as soon as
>>> possible. If this blink frame is called from V8, then calling into V8 will
>>> only result in empty values.
>>>
>>> Cheers,
>>>
>>> Yang
>>>
>>>
>>>
>>> On Sat, Nov 10, 2018 at 12:15 AM Adam Klein  wrote:
>>>
 On Thu, Nov 8, 2018 at 8:21 PM Yutaka Hirano 
 wrote:

> > As to the problem itself, I have a clarifying questions: doesn't
> Blink already have some choke point to determine whether it's "ok to call
> script now"? If so that'd be a more natural place to add this handling 
> than
> TryCatch.
>
> No, there isn't such a point. To make matters worse, some call-sites
> don't check errors because they don't care.
>
> Sorry for the ignorance but I would like to know V8's policy on
> termination.
>
> 1. What happens if the isolate is forcibly terminated (from another
> thread) while running a script? Will an exception be thrown? Is a
> v8::TryCatch catches the exception?
> 2. What happens if we try to run a script when the isolate has already
> been terminated?
> 3. What happens if v8 calls blink code, the isolate is forcibly
> terminated and then the control is back to v8?
>
>
 I'm not intimately familiar with the details here. Yang or Toon,
 perhaps you have more insight?


>
>
> 

[v8-users] using custom toolchain for V8 builds

[madana gopal]

Hi,

We are building v8 using gyp and ninja. We have our own sysroot and 
toolchain which need to be used for building v8 instead of toolchain within 
v8. We are building for target architecture arm and it is 
using arm-linux-gnueabihf-g++ as compiler always.

Do we have any way to configure it to different compiler?. Please share the 
way.

Thanks.

Regards,
Madan

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Re: How to rescue issues caused by v8::Isolate termination

[Yang Guo]

Hi,

I found that at the only place Isolate::TerminateExecution is called

from
blink, V8 is not even running. That would mean that we don't have to worry
about any of this?

Cheers,

Yang

On Wed, Nov 14, 2018 at 10:00 AM Yang Guo  wrote:

> I filed a bug for the slightly counter-intuitive behavior I mentioned:
> https://bugs.chromium.org/p/v8/issues/detail?id=8455
>
> Cheers,
>
> Yang
>
> On Wed, Nov 14, 2018 at 9:01 AM Yang Guo  wrote:
>
>> When you terminate execution in V8, we abort execution until the
>> bottom-most call into V8. If you have re-entries into V8, V8 always returns
>> empty results until the bottom-most call into V8. On the Blink side on the
>> stack of the re-entries, you can try to call into V8 before returning, but
>> that will simply return empty results. v8::TryCatch scopes along the way
>> will return true for v8::TryCatch::HasCaught and
>> v8::TryCatch::HasTerminated. Isolate::IsExecutionTerminating returns true.
>>
>> As soon as we reach the bottom-most call, we return with an empty value
>> as well. The v8::TryCatch scope around that will return true for
>> v8::TryCatch::HasCaught and v8::TryCatch::HasTerminated, but
>> Isolate::IsExecutionTerminating will return false (even if you are still
>> inside this outer-most v8::TryCatch scope), because you can safely call
>> into V8 again, from here on. I actually find this a bit counter-intuitive,
>> and it might be better to have Isolate::IsExecutionTerminating return true,
>> until we leave the outer-most v8::TryCatch. Though implementing that seems
>> a bit annoying.
>>
>> So what you are observing is that you have a non-reentry call to execute
>> the worker. That terminates, and you then have another non-reentry call.
>> That is working as intended though. Once you have left V8 through
>> termination across all re-entries, the isolate is good to be re-used again.
>> I think the correct way to fix your issue is to, at non-reentry calls, 
>> *always
>> check for v8::TryCatch::HasTerminated, and use that to guide the following
>> control flow*.
>>
>> To answer your questions:
>>
>>> 1. What happens if the isolate is forcibly terminated (from another
>>> thread) while running a script? Will an exception be thrown? Is a
>>> v8::TryCatch catches the exception?
>>
>> Internally we throw a special exception that cannot be caught by
>> javascript. This exception causes execution to abort until we arrive at the
>> first (non-reentry) call into V8.
>>
>> 2. What happens if we try to run a script when the isolate has already
>>> been terminated?
>>
>> If you completely exited V8 back to the first non-reentry call, you can
>> safely use the isolate again.
>>
>> 3. What happens if v8 calls blink code, the isolate is forcibly
>>> terminated and then the control is back to v8?
>>
>> The termination exception is propagated back to V8, causes the current
>> execution to abort, so that we return an empty value to blink as soon as
>> possible. If this blink frame is called from V8, then calling into V8 will
>> only result in empty values.
>>
>> Cheers,
>>
>> Yang
>>
>>
>>
>> On Sat, Nov 10, 2018 at 12:15 AM Adam Klein  wrote:
>>
>>> On Thu, Nov 8, 2018 at 8:21 PM Yutaka Hirano 
>>> wrote:
>>>
 > As to the problem itself, I have a clarifying questions: doesn't
 Blink already have some choke point to determine whether it's "ok to call
 script now"? If so that'd be a more natural place to add this handling than
 TryCatch.

 No, there isn't such a point. To make matters worse, some call-sites
 don't check errors because they don't care.

 Sorry for the ignorance but I would like to know V8's policy on
 termination.

 1. What happens if the isolate is forcibly terminated (from another
 thread) while running a script? Will an exception be thrown? Is a
 v8::TryCatch catches the exception?
 2. What happens if we try to run a script when the isolate has already
 been terminated?
 3. What happens if v8 calls blink code, the isolate is forcibly
 terminated and then the control is back to v8?


>>> I'm not intimately familiar with the details here. Yang or Toon, perhaps
>>> you have more insight?
>>>
>>>


 On Fri, Nov 9, 2018 at 5:30 AM Adam Klein  wrote:

> Adding a couple more V8 folks who may have thoughts.
>
> On Thu, Nov 8, 2018 at 1:59 AM Kentaro Hara 
> wrote:
>
>> On Thu, Nov 8, 2018 at 1:10 AM Yuki Shiino 
>> wrote:
>>
>>> +adamk, cbruni to get more attention from V8 team.  This needs V8
>>> team's support.
>>>
>>> Actually, I intended haraken's (a3) at my proposal (a), but I'm
>>> afraid that changing an existing API HasCaught() would break backward
>>> compatibility.  So, I'm also proposing to add a new V8 API like
>>> v8::TryCatch::HasPendingException or 
>>>