[v8-users] How does a native function return a value in new v8 versions?

2014-07-21 Thread deadmorous 
In previous v8 versions (e.g., 3.3.3), a native function passed to 
FunctionTemplate::New() had a return value:

typedef Handle (*InvocationCallback)(const Arguments& args);

Now things are different:

typedef void (*FunctionCallback)(const FunctionCallbackInfo& info);

And now my question: how to migrate native function implementation (return 
value) from v8 3.3.3 to 3.28.31? Or, simplier, just how to return a value 
from native function?

-- 
-- 
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] mips support for n32 abi

2014-07-21 Thread Flying Jester 
Are there n32 compatible Android devices? Are there any n32 incompatible 
Android devices?

V8 is really here to power Chrome, and Chrome on anything except x86 is 
really there to power Android.

On Thursday, July 17, 2014 4:02:45 PM UTC-7, Jacob Burkholder wrote:
>
> Hi, thanks for your reply.  We have decided to build v8 for abi 32 and 
> mips32r2 architcture and install the multilib glibc so that it will run 
> alongside our n32 abi apps.  I'm puzzled by your choice of abis though, 
> since n32 seems far superior to o32 or 64.  Anyway, please allow me to 
> voice my opinion that for data plane apps that have a WebUI, n32 is the 
> perferred choice of abi and choosing o32 or 64 causes us to waste ram and 
> flash installing multiple glibcs and other libraries :).
>
> Thanks for you help,
>
> Jake
>
> On Tuesday, July 15, 2014 9:18:40 PM UTC-4, paul lind wrote:
>>
>> Hi Jacob - 
>>
>> Currently, we do not plan to support n32 ABI in v8, but I'm happy to give 
>> you some pointers that should help if you want to give it a go. You're 
>> right that it is mostly about FP register use and the ABI's when calling 
>> between C code and the JIT'ed code. There is good info in Domenic 
>> Sweetman's "See MIPS Run" book.
>>
>> The existing O32 ABI uses FP registers in a backward-compatibility mode 
>> called 'fp32', where the 32 FP registers are only 32-bits each, and to 
>> store a double, a pair of FP registers are used. The n32 and n64 ABI's use 
>> 'fp64' mode, where each of the 32 FP registers are 64-bits wide. This 
>> changes how code must load these registers. You will need to use fp64 mode 
>> for your n32 version of v8. The good news is that we are working on this 
>> change currently, and I would hope that we have it upstreamed in the next 
>> 3-4 weeks. For now, you can look at this branch, which implements fp64 mode 
>> on mips32 v8 (in an older version of v8): 
>> https://github.com/paul99/v8m-rb/tree/dm-dev-fp64. We also use fp64 mode 
>> in the mips64 v8.
>>
>> Something to keep in mind is that MIPS cpus require doubles to be 8-byte 
>> aligned, and 32-bit v8 only maintains 4-byte alignment. So we do not use 
>> the normal ldc1/sdc1 instructions to load/store doubles, we load/store 
>> 32-bits at a time. See 
>> https://github.com/paul99/v8m-rb/blob/dm-dev-fp64/src/mips/assembler-mips.cc#L1628
>>  
>> for how this is done in the two different FP modes. (There are other 
>> changes as well, look at the full commit.)
>>
>> For the ABI issues, you can look at the mips64 port, and search for 
>> 'MIPS_ABI_N64' and 'kMipsAbi'. For example, 
>> https://github.com/v8/v8/blob/master/src/mips64/code-stubs-mips64.cc#L2582. 
>> You'll need to make similar changes in the 32-bit v8 to support n32.
>>
>> Hope this helps,
>>
>> paul
>>
>> On Jul 15, 2014, at 7:40 AM, Jacob Burkholder  
>> wrote:
>>
>> Hello, I have an embedded big endian mips target that I'd like to use v8 
>> on and would like to use n32 abi.  I understand that only o32 is currently 
>> supported.  It seems that the difference in floating point registers and 
>> calls to native runtime functions due to different argument registers and 
>> different stack slot size are what will be affected.  Is there something 
>> else?  Is anyone working on this or can give me an overview of what changes 
>> need to be made?  I've poked around a bit in the v8 source code and am 
>> somewhat familiar.
>>
>> Thanks.
>>
>> -- 
>> -- 
>> v8-users mailing list
>> v8-u...@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+u...@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.

Re: [v8-users] Building V8 for ARMv6 (Raspberry Pi), got illegal instruction (movw)

2014-07-21 Thread Ross McIlroy 
Actually, Rodolph just pointed out that running: d8 --help | head -n 2 will
output the same information as
v8::internal::CpuFeatures::PrintFeatures/PrintTarget,
so you should be able to do this instead of the gdb commands I suggested in
the last message.

Cheers,
Ross



On 21 July 2014 17:30, Ross McIlroy  wrote:

> Hi Dirk,
>
> The stack trace looks like the movw is being emitted in generated code.
>  Could you try again with a debug build of V8 which includes r22512 (
> https://codereview.chromium.org/402923002/) - this should fail with an
> ASSERT error if V8 tries to emit a movw instruction on an armv6 target.
>
> If this doesn't throw an assert, then it looks like the runtime probing is
> incorrectly concluding that the device is capable of running armv7 code
> even although V8 was only compiled for armv6.  Could you send the output of
> running the following commands in gdb at the point of the crash:
>   p v8::internal::CpuFeatures::PrintFeatures()
> and
>   p v8::internal::CpuFeatures::PrintTarget()
>
> Cheers,
> Ross
>
>
>
> On 21 July 2014 10:00, Dirk Grabbert  wrote:
>
>> This is the line I'm using to find any "movw" in the objdump of the shell:
>>
>> arm-unknown-linux-gnueabihf-objdump -d out/arm.release/shell | grep -i
>> movw
>>
>>
>> Got this output:
>>
>> 0006e738 <_ZNK2v88internal11Instruction18ImmedMovwMovtValueEv>:
>>6eba4: eb09774c bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>>6f060: eb09761d bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>>6f1e4: eb0975bc bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>>6f28c: eb097592 bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>>6f2cc: eb097582 bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>>6f39c: eb09754e bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>>6f45c: eb09751e bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>>6f7ec: eb09743a bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>>6f82c: eb09742a bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>>76854: eb095820 bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>>76868: ebffdfb2 bl 6e738
>> <_ZNK2v88internal11Instruction18ImmedMovwMovtValueEv>
>>76874: ebffdfaf bl 6e738
>> <_ZNK2v88internal11Instruction18ImmedMovwMovtValueEv>
>>76894: eb095810 bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>>768a8: ebffdfa2 bl 6e738
>> <_ZNK2v88internal11Instruction18ImmedMovwMovtValueEv>
>>768b4: ebffdf9f bl 6e738
>> <_ZNK2v88internal11Instruction18ImmedMovwMovtValueEv>
>>769dc: eb0957be bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>>769ec: ebffdf51 bl 6e738
>> <_ZNK2v88internal11Instruction18ImmedMovwMovtValueEv>
>>769f8: ebffdf4e bl 6e738
>> <_ZNK2v88internal11Instruction18ImmedMovwMovtValueEv>
>>7724c: eb0955a2 bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>>77260: ebffdd34 bl 6e738
>> <_ZNK2v88internal11Instruction18ImmedMovwMovtValueEv>
>>77274: ebffdd2f bl 6e738
>> <_ZNK2v88internal11Instruction18ImmedMovwMovtValueEv>
>>77590: eb0954d1 bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>>775a8: ebffdc62 bl 6e738
>> <_ZNK2v88internal11Instruction18ImmedMovwMovtValueEv>
>>775bc: ebffdc5d bl 6e738
>> <_ZNK2v88internal11Instruction18ImmedMovwMovtValueEv>
>>   151b70: eb05eb59 bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>>   151df4: eb05eab8 bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>>   152c44: eb05e724 bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>>   152c80: eb05e715 bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>>   152dd4: eb05e6c0 bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>>   152e10: eb05e6b1 bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>>   152ef0: eb05e679 bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>>   153128: eb05e5eb bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>>   153164: eb05e5dc bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>>   1533b0: eb05e549 bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>>   1533ec: eb05e53a bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>>   153750: eb05e461 bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>>   1537a8: eb05e44b bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>>   15385c: eb05e41e bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>>   153898: eb05e40f bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>>   1539d4: eb05e3c0 bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>>   153a10: eb05e3b1 bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>>   153b4c: eb05e362 bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>>   153b88: eb05e353 bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>>   153cb4: eb05e308 bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>>   153cf0: eb05e2f9 bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>>   1541c0: eb05e1c5 bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>>   1541fc: eb05e1b6 bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>>   1559f4: eb05dbb8 bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>>   155a30: eb05dba9 bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>>   155b10: eb05db71 bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>>

Re: [v8-users] Building V8 for ARMv6 (Raspberry Pi), got illegal instruction (movw)

2014-07-21 Thread Ross McIlroy 
Hi Dirk,

The stack trace looks like the movw is being emitted in generated code.
 Could you try again with a debug build of V8 which includes r22512 (
https://codereview.chromium.org/402923002/) - this should fail with an
ASSERT error if V8 tries to emit a movw instruction on an armv6 target.

If this doesn't throw an assert, then it looks like the runtime probing is
incorrectly concluding that the device is capable of running armv7 code
even although V8 was only compiled for armv6.  Could you send the output of
running the following commands in gdb at the point of the crash:
  p v8::internal::CpuFeatures::PrintFeatures()
and
  p v8::internal::CpuFeatures::PrintTarget()

Cheers,
Ross



On 21 July 2014 10:00, Dirk Grabbert  wrote:

> This is the line I'm using to find any "movw" in the objdump of the shell:
>
> arm-unknown-linux-gnueabihf-objdump -d out/arm.release/shell | grep -i
> movw
>
>
> Got this output:
>
> 0006e738 <_ZNK2v88internal11Instruction18ImmedMovwMovtValueEv>:
>6eba4: eb09774c bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>6f060: eb09761d bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>6f1e4: eb0975bc bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>6f28c: eb097592 bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>6f2cc: eb097582 bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>6f39c: eb09754e bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>6f45c: eb09751e bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>6f7ec: eb09743a bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>6f82c: eb09742a bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>76854: eb095820 bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>76868: ebffdfb2 bl 6e738
> <_ZNK2v88internal11Instruction18ImmedMovwMovtValueEv>
>76874: ebffdfaf bl 6e738
> <_ZNK2v88internal11Instruction18ImmedMovwMovtValueEv>
>76894: eb095810 bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>768a8: ebffdfa2 bl 6e738
> <_ZNK2v88internal11Instruction18ImmedMovwMovtValueEv>
>768b4: ebffdf9f bl 6e738
> <_ZNK2v88internal11Instruction18ImmedMovwMovtValueEv>
>769dc: eb0957be bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>769ec: ebffdf51 bl 6e738
> <_ZNK2v88internal11Instruction18ImmedMovwMovtValueEv>
>769f8: ebffdf4e bl 6e738
> <_ZNK2v88internal11Instruction18ImmedMovwMovtValueEv>
>7724c: eb0955a2 bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>77260: ebffdd34 bl 6e738
> <_ZNK2v88internal11Instruction18ImmedMovwMovtValueEv>
>77274: ebffdd2f bl 6e738
> <_ZNK2v88internal11Instruction18ImmedMovwMovtValueEv>
>77590: eb0954d1 bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>775a8: ebffdc62 bl 6e738
> <_ZNK2v88internal11Instruction18ImmedMovwMovtValueEv>
>775bc: ebffdc5d bl 6e738
> <_ZNK2v88internal11Instruction18ImmedMovwMovtValueEv>
>   151b70: eb05eb59 bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>   151df4: eb05eab8 bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>   152c44: eb05e724 bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>   152c80: eb05e715 bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>   152dd4: eb05e6c0 bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>   152e10: eb05e6b1 bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>   152ef0: eb05e679 bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>   153128: eb05e5eb bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>   153164: eb05e5dc bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>   1533b0: eb05e549 bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>   1533ec: eb05e53a bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>   153750: eb05e461 bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>   1537a8: eb05e44b bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>   15385c: eb05e41e bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>   153898: eb05e40f bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>   1539d4: eb05e3c0 bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>   153a10: eb05e3b1 bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>   153b4c: eb05e362 bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>   153b88: eb05e353 bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>   153cb4: eb05e308 bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>   153cf0: eb05e2f9 bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>   1541c0: eb05e1c5 bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>   1541fc: eb05e1b6 bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>   1559f4: eb05dbb8 bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>   155a30: eb05dba9 bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>   155b10: eb05db71 bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>   1587d8: eb05d03f bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>   159a98: eb05cb8f bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>   159ad4: eb05cb80 bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>   159c08: eb05cb33 bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>   159fc4: eb05ca44 bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>   15a000: eb05ca35 bl 2cc8dc <_ZN2v88internal9Assembler6IsMovWEi>
>   15a44c: eb05c9

Re: [v8-users] why messages.js is in JavaScript

2014-07-21 Thread 'Andreas Rossberg' via v8-users 
On 21 July 2014 12:58, Refael Ackermann  wrote:
> Does anyone know why messages.js exists as a JavaScript file, and is not
> implemented in C++?

Why should it be, when it's easier to self-host in JS itself?

/Andreas

-- 
-- 
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] why messages.js is in JavaScript

2014-07-21 Thread Refael Ackermann 
Does anyone know why messages.js exists as a JavaScript file, and is not 
implemented in C++?

-- 
-- 
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] Building V8 for ARMv6 (Raspberry Pi), got illegal instruction (movw)

2014-07-21 Thread Dirk Grabbert 
Here is a screenshot of gdb.


Cheers,
Dirk.

Am Freitag, 18. Juli 2014 17:37:13 UTC+2 schrieb Ross McIlroy:
>
> I don't have an armv6 device to test on here, but I tried with a simulator 
> build with added asserts in Assembler::movw/movt to ensure that they aren't 
> emitted when targeting armv6 and these asserts didn't trigger, so I'm not 
> sure where the movw instruction is being emitted.
>
> Could you let me know the exact version / revision of V8 you are building 
> and the stack trace generated by gdb?
>
> Cheers,
> Ross
>  
>
>> On 17 July 2014 17:04, Dirk Grabbert > 
>> wrote:
>> I'm trying to build V8 for the Raspberry Pi (toolchain from the 
>> archlinuxarm website, nodejs works fine). Buildprocess works without any 
>> errors, but trying to execute the shell or d8 brings up an illegal 
>> instruction. GDB shows that it's "movw".
>> To build I've exported CC, CXX, LINK, AR and LD and then run "make 
>> snapshot=off i18nsupport=off armv7=false armfpu=vfp2 arm.release -j5" (or 
>> armfpu=vfp, there is no change in the output).
>> -- 
>> -- 
>> v8-users mailing list
>> v8-u...@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+u...@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.