Re: [v8-users] Add recognition of unused Arm opcode to prevent runtime error

On Fri, Feb 27, 2015 at 11:19 PM, Malek Musleh wrote: > ok, that works for seeing the native dissambly. > > 1) > But how do I enable use of the arm simulator? I see simulator related > options (.e.g --trace_sim) but that doesn't seem to do anything in > terms of simulating the program execution u

Re: [v8-users] Add recognition of unused Arm opcode to prevent runtime error

ok, that works for seeing the native dissambly. 1) But how do I enable use of the arm simulator? I see simulator related options (.e.g --trace_sim) but that doesn't seem to do anything in terms of simulating the program execution under an arm platform. 2) Is it possible to see the assembly code f

Re: [v8-users] Intent to Implement: ES6 Reflect.apply / Reflect.construct

SGTMx2 On Fri, Feb 27, 2015 at 5:12 PM, 'Andreas Rossberg' via v8-users < v8-users@googlegroups.com> wrote: > Sounds good to me. > > On 27 February 2015 at 15:56, Caitlin Potter > wrote: > >> *Contact emails* >> caitpotte...@gmail.com, >> >> *Spec* >> Reflect.apply() >>

Re: [v8-users] Re: Simple development queries

On Fri, Feb 27, 2015 at 6:56 PM, Deepak Subramanian wrote: > I am relatively new to v8. Please note, I would like this to run in > un-modified d8 while modifying v8 only. Thanks. > > > On Friday, February 27, 2015 at 6:52:18 PM UTC+1, Deepak Subramanian wrote: >> >> Query 1: >> The v8natives.js s

[v8-users] Re: Simple development queries

I am relatively new to v8. Please note, I would like this to run in un-modified d8 while modifying v8 only. Thanks. On Friday, February 27, 2015 at 6:52:18 PM UTC+1, Deepak Subramanian wrote: > > Query 1: > The v8natives.js seem to have a references to various functions created by > the macros i

[v8-users] Simple development queries

Query 1: The v8natives.js seem to have a references to various functions created by the macros in runtime.* and these are referenced by a %(FUNCTIONName) kind of call. Is this a correct understanding ? And what do the capital functions in the same file mean. Query 2: I am looking for the best w

[v8-users] Intent to ship: ES6 computed property names

[blink-dev: FYI] Computed property names allows an expression to compute the name of a property, both in classes and object literals. let object = { [40 + 2]: 'meaning?' }; The main use case for these are for using symbol keys as property names. class Iterable { *[Symbol.iterator]() { yield

Re: [v8-users] Add recognition of unused Arm opcode to prevent runtime error

If you are using release d8 then you need to add the disassembler to get the trace. make arm.release disassembler=on On 27 February 2015 at 16:43, Malek Musleh wrote: > I'll focus on using the built in v8 simulator. I'm primarily > interested in the instruction trace of the runtime when handling

Re: [v8-users] Add recognition of unused Arm opcode to prevent runtime error

I'll focus on using the built in v8 simulator. I'm primarily interested in the instruction trace of the runtime when handling an IC miss. Can you specify how I can see the arm dissembly produced by the arm simulator? You said the arm simulator gets built automatically when not running on an arm hos

Re: [v8-users] Add recognition of unused Arm opcode to prevent runtime error

Your instrumentation function will likely crash wherever you call it from. The issue is that you cannot thrash lr at random as it likely contains the return address of your function. Once you fixed your magic instruction behaviour, the simplest way to add an instruction in the emitted code is to c

Re: [v8-users] Intent to Implement: ES6 Reflect.apply / Reflect.construct

Sounds good to me. On 27 February 2015 at 15:56, Caitlin Potter wrote: > *Contact emails* > caitpotte...@gmail.com, > > *Spec* > Reflect.apply() > > https://people.mozilla.org/%7Ejorendorff/es6-draft.html#sec-reflect.ap

Re: [v8-users] Add recognition of unused Arm opcode to prevent runtime error

Yes, that sounds correct. It seems that I should be 1) instrumenting the generated code, or at least have 2) the magic instruction be generated along with the rest of the generated code. I tried to move up the call one level to CallIC::handleMiss in v8/src/ic/ic.cc, but that causes a seg fault (r

[v8-users] Intent to Implement: ES6 Reflect.apply / Reflect.construct

*Contact emails* caitpotte...@gmail.com, *Spec* Reflect.apply() https://people.mozilla.org/%7Ejorendorff/es6-draft.html#sec-reflect.apply Reflect.construct()

Re: [v8-users] API changes upcoming to make writing exception safe code more easy

On Fri, Feb 27, 2015 at 3:26 PM Ben Noordhuis wrote: > On Fri, Feb 27, 2015 at 11:43 AM, Michael Hablich > wrote: > > Hey v8-users, > > > > we're making big changes to the api (again). We've found that our api > makes > > it extremely difficult to write exception safe code. > > > > Reference is

Re: [v8-users] API changes upcoming to make writing exception safe code more easy

On Fri, Feb 27, 2015 at 11:43 AM, Michael Hablich wrote: > Hey v8-users, > > we're making big changes to the api (again). We've found that our api makes > it extremely difficult to write exception safe code. > > Reference issue > https://code.google.com/p/v8/issues/detail?id=3929 > > Further desc

Re: [v8-users] Best environment to build V8

Thanks Louis, I'll give it a try and see if that fixes my problems! On Thursday, 26 February 2015 20:51:25 UTC-5, Louis P. Santillan wrote: > > I build on Ubuntu ia32 & x86_64, as well as OSX 10.10 (which is now > strictly x86_64). I also build on Debian arm (Raspberry Pi Model B, very > slow)

Re: [v8-users] Huge libv8_base.a (over 250Mb) when building for x64.release

I think the link to the stack overflow post I posted was misguiding, as it's not actually "my" code and I was actually referring to http://stackoverflow.com/questions/24279237/android-ndk-linking-v8-static-library-cannot-find-symbols-but-they-are-there?answertab=active#tab-top (the patch secti

[v8-users] API changes upcoming to make writing exception safe code more easy

Hey v8-users, we're making big changes to the api (again). We've found that our api makes it extremely difficult to write exception safe code. *Reference issue* https://code.google.com/p/v8/issues/detail?id=3929 *Further description* Consider the following: Local x = some_value; s = x.ToStrin