Always use CpuFeaturesImpliedByCompiler() when selecting CPU features. This checks both for CAN_USE_ARMV7_INSTRUCTIONS and CAN_USE_VFP_INSTRUCTIONS and for GCC preprocessor symbols. This will support using the CAN_USE_XXX for a simulator build used for generating a snapshot followed by a crosscompile using -march= and -mfpu= for selecting the (minimal) target device CPU features. The snapshot will use instructions based on the CAN_USE_XXX whereas the target will at least use features based on both CAN_USE_XXX and -march= and -mfpu=, but will try runtime CPU feature detection a well looking for somethis better.
Remove the compiler based CPU feature detection from the OS::CpuFeaturesImpliedByPlatform() as it did not belong there. Also was already in the CpuFeaturesImpliedByCompiler().
Add the variable 'v8_can_use_vfp_instructions' to the GYP file which can be used to turn on CAN_USE_VFP_INSTRUCTIONS when building V8. I did not add any -mfpu= cflags for this, as there are several options here (e.g. vfp and neon).
R=erik.corry@gmail.com, karlklose@chromium.org
BUG=none
TEST=none
Review URL: http://codereview.chromium.org//6904164
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7754 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Add option armeabi to the SCons build for selecting the floating point variant to use. Also add externally defined CCFLAGS environment for all targets. Run test.py with option -S armeabi=hardfloat to test with hardfloat enabled.
Make selecting hardfloat EABI variant a build-time option instead of a runtime option.
Add a simple check of the EABI variant during V8 initialization to exit if the compilation was not configured correctly. The reason for this is that GCC does not provide a compile time symbol defining the EABI variant. This check is not fool-proof as it cannot check the compilation configuration used for the snapshot if any.
R=karlklose@chromium.org, erik.corry@gmail.com
BUG=none
TEST=none
Review URL: http://codereview.chromium.org//6905098
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7715 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Patch by Dmitry Lomov.
pthreads implementations are free to reuse pthread_t (thread id) after
the thread has died. This change gets rid of ThreadHandle class and
replaces it with v8-managed thread identifiers.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7575 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This commit adds current working versions of assembler, macro-assembler,
disassembler, and simulator.
All other mips arch files are replaced with stubbed-out versions that
will build.
Arch independent files are updated as needed to support building and
running mips.
The only test is cctest/test-assembler-mips, and this passes on the
simulator and on mips hardware.
TEST=none
BUG=none
Patch by Paul Lind from MIPS.
Review URL: http://codereview.chromium.org/6730029/
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7388 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Windows compilation is broken. Will fix and reland later.
This reverts commit fe13ffaa6d0c3435bfe1ae930813e456650ec980.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6389 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
the only platform that it works on is linux (using the prctl API to set the
names of the threads). Other platforms are setup to build properly if the
flag is set, but their thread names are not currently set.
Patch by Mark Lam from Hewlett-Packard Development Company, LP
Review URL: http://codereview.chromium.org/6070009
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6141 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Instead of relying on itimer signals from kernel, send them
ourselves from a separate thread. This disables an ability
to profile multiple VM threads on Linux, but it anyway doesn't
work on other platforms, so we need a common solution for
it (issue 913 created to track this).
Review URL: http://codereview.chromium.org/4000007
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5711 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Since 2.6.31 perf_events interface has been available in the
kernel. There's a nice tool called "perf" (linux-2.6/tools/perf) that
uses this interface and provides capabilities similar to oprofile. The
simplest form of its usage is just dumping the raw log (trace) of
events generated by the kernel. In this patch I'm adding a script
(tools/ll_prof.py) to build profiles based on perf trace and our code
log. All the heavy-lifting is done by perf. Compared to oprofile agent
this approach does not require recompilation and supports code moving
garbage collections.
Expected usage is documented in the ll_prof's help. Basically one
should run V8 under perf passing --ll-prof flag and then the produced
logs can be analyzed by tools/ll_prof.py.
The new --ll-prof flag enables logging of generated code object
locations and names (like --log-code), and also of their bodies, which
can be later disassembled and annotated by the script.
Review URL: http://codereview.chromium.org/3831002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5663 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This patch manually randomizes the allocation address for PAGE_EXECUTE_READWRITE regions between kAllocationRandomAddressMin and kAllocationRandomAddressMax.
BUG=none
TEST=allocate lots of javascript code and check for contiguous allocations
Patch by Paul Mehta <pmehta@chromium.org>
Review URL: http://codereview.chromium.org/2832095
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5169 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This is to make possible enabling usage of the new profiling subsystem
in Chromium without much hassle. The idea is pretty simple: unless the
new profiling API is used, all works as usual, as soon as Chromium
starts to use the new API, it will work too.
Review URL: http://codereview.chromium.org/1635005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4382 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
In browser (DevTools) mode, only non-native JS code and callbacks are reported.
Also, added "(garbage collector)" entry which accumulates samples count in GC state.
Trying to display "(compiler)" and "(external)" only brings confusion,
because it ends up in displaying scripts code under "(compiler)" node, and DOM
event handlers under "(external)" node, which looks weird.
Review URL: http://codereview.chromium.org/1523015
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4357 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
On 'usual' Linux systems in '/proc/self/maps' we encounter two entries
per library: one has 'rw-p' attrs and the other has 'r-xp'. While on
Android, I see 'rwxp' and 'r-xp' (both entries are marked executable.)
So I've added an explicit check for non-writability to leave only a
single record in the log file.
Review URL: http://codereview.chromium.org/661467
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4018 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
