Re: [chromium-dev] Re: Building chromium for arm--erroring out
2009/12/14 Sofia Tahseen sofia.tahs...@gmail.com Hi Antoine, I did exactly what you said-- not set armv7=1 in gyp_defines. export GYP_DEFINES=target_arch=arm sysroot=~/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root disable_nacl=1 use_system_ffmpeg=1 I rebuilt chromium. And then I reset my kernel so that it does not use NEON. This does not help and the browser keeps crashing again even though I do not set armv7=1 in gyp_defines. So is there a way to disable neon settings on chromium browser and make chromium working on a hardware that does not support NEON? Is it still crashing in S32A_Opaque_BlitRow32_neon ? Thanks, Sofia On Fri, Dec 11, 2009 at 5:39 PM, Antoine Labour pi...@chromium.orgwrote: On Fri, Dec 11, 2009 at 3:28 PM, Sofia Tahseen sofia.tahs...@gmail.comwrote: Hi Joel/Erik/All, I don't think armv5 is an issue. Reason being I used the jaunty armv5 libraries to build chrome. I tried to debug the issue with gdb. gdb chrome GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as arm-linux-gnueabi... (gdb) (gdb) run Starting program: /home/adas/Release/chrome [Thread debugging using libthread_db enabled] [New Thread 0x4112ac80 (LWP 9722)] [New Thread 0x41d49440 (LWP 9727)] [New Thread 0x42549440 (LWP 9728)] [New Thread 0x42d49440 (LWP 9729)] [New Thread 0x43549440 (LWP 9730)] [New Thread 0x43d49440 (LWP 9731)] [New Thread 0x44549440 (LWP 9732)] [New Thread 0x44d49440 (LWP 9733)] [New Thread 0x44d69440 (LWP 9734)] [New Thread 0x458ff440 (LWP 9738)] [New Thread 0x460ff440 (LWP 9739)] [Thread 0x460ff440 (LWP 9739) exited] Program received signal SIGILL, Illegal instruction. [Switching to Thread 0x4112ac80 (LWP 9722)] 0x0081caec in S32A_Opaque_BlitRow32_neon () Current language: auto; currently asm The error S32A_Opaque_BlitRow32_neon () had to do something with the floating point setting of the kernel. I checked my kernel configuration and neon was not set. So I set it and it rebuild my kernel and booted my jaunty. Now it works perfectly...without any crashes. Key : In order to run chromium we need to set the neon in the kernel configuration. Note, if you don't set armv7=1 when you build chromium, it shouldn't use the NEON paths, so you shouldn't run into that problem. But it's better to enable it in the kernel if your hardware supports it. Antoine Regards, Sofia On Fri, Dec 11, 2009 at 2:27 AM, Erik Corry erik.co...@gmail.comwrote: 2009/12/10 Sofia Tahseen sofia.tahs...@gmail.com: You are so right, Joel... I corrected my .so and now I could build the chrome browser ...finally!! I copied the whole /src/out/Release directory to my jaunty on the BeagleBoard(256MB RAM). I try to launch chrome through: ./chrome It starts up chrome, and then immediately kills chrome. I get an Illegal Instruction. I restart and I can now see chrome as shown in the attachment but I cannot browse. When I reload the page, it again kills chrome saying Illegal instruction. Has anyone seen this before? I have my proxy settings set too.. This could be anything, but it might be this bug in some versions of gcc: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39604 If that's it then adding -fno-tree-sink to the flags used for V8 will help. It's a bug that only shows up on ARM and only on some versions of gcc. Any help is highly appreciated. Thanks, Sofia On Wed, Dec 9, 2009 at 6:00 PM, Joel Stanley j...@chromium.org wrote: On Thu, Dec 10, 2009 at 05:14, Sofia Tahseen sofia.tahs...@gmail.com wrote: /home/adas/0_Data/0_Lin/091203_Chromium_OS/toolchain/arm-2009q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/../../../../arm-none-linux-gnueabi/bin/ld: skipping incompatible /home/adas/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root/usr/lib/librt.so when searching for -lrt The errors are indicative of trying to link against libraries from a different platform. To confirm: check the output of $ 'file /home/adas/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root/usr/lib/librt.so I suspect it will tell you it's a symbolic link to /lib/librt.so.1, which itself is a symbolic link to /lib/librt-2.10.2.so - note these paths are relative to /, not to your sysroot directory. You have two slightly solutions - adjust the symlinks in sys-root/usr/lib so they point to the files in sys-root//lib - replace the smymlinks with the actual libraries, ie copy files from sys-root/lib to sys-root/usr/lib I would be happy to hear a neater solution for this, but the above worked for me. Cheers, Joel
Re: [chromium-dev] Re: Building chromium for arm--erroring out
2009/12/10 Sofia Tahseen sofia.tahs...@gmail.com: You are so right, Joel... I corrected my .so and now I could build the chrome browser ...finally!! I copied the whole /src/out/Release directory to my jaunty on the BeagleBoard(256MB RAM). I try to launch chrome through: ./chrome It starts up chrome, and then immediately kills chrome. I get an Illegal Instruction. I restart and I can now see chrome as shown in the attachment but I cannot browse. When I reload the page, it again kills chrome saying Illegal instruction. Has anyone seen this before? I have my proxy settings set too.. This could be anything, but it might be this bug in some versions of gcc: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39604 If that's it then adding -fno-tree-sink to the flags used for V8 will help. It's a bug that only shows up on ARM and only on some versions of gcc. Any help is highly appreciated. Thanks, Sofia On Wed, Dec 9, 2009 at 6:00 PM, Joel Stanley j...@chromium.org wrote: On Thu, Dec 10, 2009 at 05:14, Sofia Tahseen sofia.tahs...@gmail.com wrote: /home/adas/0_Data/0_Lin/091203_Chromium_OS/toolchain/arm-2009q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/../../../../arm-none-linux-gnueabi/bin/ld: skipping incompatible /home/adas/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root/usr/lib/librt.so when searching for -lrt The errors are indicative of trying to link against libraries from a different platform. To confirm: check the output of $ 'file /home/adas/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root/usr/lib/librt.so I suspect it will tell you it's a symbolic link to /lib/librt.so.1, which itself is a symbolic link to /lib/librt-2.10.2.so - note these paths are relative to /, not to your sysroot directory. You have two slightly solutions - adjust the symlinks in sys-root/usr/lib so they point to the files in sys-root//lib - replace the smymlinks with the actual libraries, ie copy files from sys-root/lib to sys-root/usr/lib I would be happy to hear a neater solution for this, but the above worked for me. Cheers, Joel -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: enabling javascript strict warnings and errors?
2009/12/5 nachumk nach...@gmail.com: On Dec 5, 3:48 pm, Erik Corry erik.co...@gmail.com wrote: 2009/12/5 nachumk nach...@gmail.com: Hi, I'm using Chrome 4.0.249.25. Is there a way to enable chrome's javascript to be more verbose and to break on errors such as an undeclared variable (i don't want to implicity declare them)? Not in Chrome. You might want to look into the JS compilerhttp://closure-compiler.appspot.com/homehttp://googlecode.blogspot.com/2009/11/introducing-closure-tools.html Thanx, nachum -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev Thanx for the quick response. Do you know what flags can be used with chrome's startup switch js-flags, or where that documentation exists? Here are the ones supported by the standalone V8 shell. Not all of them will work in Google Chrome. Some of them will cause your browser to be incompatible, slower, insecure or crashy. For the boolean ones you insert no (without a dash or underscore) after the double dash to indicate they should be false. --debug_code (generate extra code (comments, assertions) for debugging) type: bool default: false --emit_branch_hints (emit branch hints) type: bool default: false --push_pop_elimination (eliminate redundant push/pops in assembly code) type: bool default: true --print_push_pop_elimination (print elimination of redundant push/pops in assembly code) type: bool default: false --expose_natives_as (expose natives in global object) type: string default: NULL --expose_debug_as (expose debug in global object) type: string default: NULL --natives_file (alternative natives file) type: string default: NULL --expose_gc (expose gc extension) type: bool default: false --stack_trace_limit (number of stack frames to capture) type: int default: 10 --inline_new (use fast inline allocation) type: bool default: true --stack_trace_on_abort (print a stack trace if an assertion failure occurs) type: bool default: true --trace (trace function calls) type: bool default: false --defer_negation (defer negation operation) type: bool default: true --check_stack (check stack for overflow, interrupt, breakpoint) type: bool default: true --lazy (use lazy compilation) type: bool default: true --debug_info (add debug information to compiled functions) type: bool default: true --strict (strict error checking) type: bool default: false --min_preparse_length (Minimum length for automatic enable preparsing) type: int default: 1024 --compilation_cache (enable compilation cache) type: bool default: true --remote_debugging (enable remote debugging) type: bool default: false --trace_debug_json (trace debugging JSON request/response) type: bool default: false --debugger_auto_break (automatically set the debug break flag when debugger commands are in the queue (experimental)) type: bool default: false --max_stack_trace_source_length (maximum length of function source code printed in a stack trace.) type: int default: 300 --new_space_size (size of (each semispace in) the new generation) type: int default: 0 --old_space_size (size of the old generation) type: int default: 0 --gc_global (always perform global GCs) type: bool default: false --gc_interval (garbage collect after n allocations) type: int default: -1 --trace_gc (print one trace line following each garbage collection) type: bool default: false --trace_gc_verbose (print more details following each garbage collection) type: bool default: false --collect_maps (garbage collect maps from which no objects can be reached) type: bool default: true --use_idle_notification (Use idle notification to reduce memory footprint.) type: bool default: true --use_ic (use inline caching) type: bool default: true --native_code_counters (generate extra code for manipulating stats counters) type: bool default: false --always_compact (Perform compaction on every full GC) type: bool default: false --never_compact (Never perform compaction on full GC - testing only) type: bool default: false --cleanup_ics_at_gc (Flush inline caches prior to mark compact collection.) type: bool default: true --cleanup_caches_in_maps_at_gc (Flush code caches in maps during mark compact cycle.) type: bool default: true --canonicalize_object_literal_maps (Canonicalize maps for object literals.) type: bool default: true --h (print this message) type: bool default: false --allow_natives_syntax (allow natives syntax) type: bool default: false --optimize_ast
Re: [chromium-dev] enabling javascript strict warnings and errors?
2009/12/5 nachumk nach...@gmail.com: Hi, I'm using Chrome 4.0.249.25. Is there a way to enable chrome's javascript to be more verbose and to break on errors such as an undeclared variable (i don't want to implicity declare them)? Not in Chrome. You might want to look into the JS compiler http://closure-compiler.appspot.com/home http://googlecode.blogspot.com/2009/11/introducing-closure-tools.html Thanx, nachum -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Re: Which editor do you recommend on Mac OS X?
2009/11/3 Paweł Hajdan Jr. phajdan...@chromium.org: Recently I started working more and more on Mac OS X, and I'm trying to find an editor that would work the best for me. On Linux I used GNU Emacs with many customizations. Some of the most handy ones for working on Chromium were Google Style script and launching the compilation from the editor. I also used Vim keybindings (Viper) a lot. On Mac, I tried Aquamacs, but some of my customizations broke. Also, the Vim emulation seems to be only half-working (selecting text in Vim visual mode isn't working). I also tried Xcode, but it seems that the editor isn't powerful enough. I don't know how to quickly remove an entire line (2 keystrokes in Vim), or a few lines (3 keystrokes). However, the Open Quickly option (cmd-shift-d) is very nice. I also couldn't find an easy solution to automatically remove trailing whitespace in Xcode. Do you have any tips about effective editing on Mac? Which solution would you recommend? Vim? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Why is Linux Chrome so fast?
Do you have anti-virus software on your Windows machines? 2009/10/28 Adam Barth aba...@chromium.org: My three laptops have relatively comparable hardware and run Chrome on Windows, Mac, and Linux respectively. The Linux version of Chrome feels ridiculously faster than Windows and Mac. Do we understand why this is? Can we make Windows and Mac feel that fast too? General observations: 1) Scroll performance is extremely good. Even on Gmail, I can only get the mouse to lead the scroll bar by a dozen pixels. On Slashdot, it doesn't even look like I can do that. 2) Tab creation is very fast. Maybe the zygote is helping here? Can we pre-render the NTP on other platforms? 3) Startup time is faster than calculator. Adam --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Canary bot, now with formatted layout test results
This makes me very happy! 2009/10/15 Glenn Wilson gwil...@chromium.org: Hi Webkit gardeners, The Windows canary bot now generates formatted layout test results on each build that had unexpected failing layout tests, which means you can quickly see layout test failures, diffs, and upstream baselines without running the tool manually. The goal of this output is to help gardeners assess what may have changed, and how to best handle the failure. For example, here are the failures for build 13359: http://build.chromium.org/buildbot/layout_test_results/webkit-rel-webkit-org/29119/index-13359.html To see the formatted layout test failures for a specific canary build, just click on the layout test results link in the archive webkit test results step, then click on the index-.html file. There's still more work to do, including getting the formatter working properly on the Mac Linux canaries, adding flakiness data, adding a link directly to the waterfall display, and more. Many thanks go to Ojan, Nicolas and all others who endured my many code reviews, and Eric Roman and Dimitri for the original spec and design. Please let me know what you think, and what changes you'd like to see. Glenn -- Erik Corry, Software Engineer Google Denmark ApS. CVR nr. 28 86 69 84 c/o Philip Partners, 7 Vognmagergade, P.O. Box 2227, DK-1018 Copenhagen K, Denmark. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] The Great Webkit Comparison Table
On quirksmode, sponsored by Google, apparently: http://www.quirksmode.org/blog/archives/2009/10/there_is_no_web.html -- Erik Corry, Software Engineer Google Denmark ApS. CVR nr. 28 86 69 84 c/o Philip Partners, 7 Vognmagergade, P.O. Box 2227, DK-1018 Copenhagen K, Denmark. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Cross-compiling on ARM
2009/8/21 Antoine Labour pi...@google.com: There's growing interest from several parties in getting Chrome to cross-compile onto linux/ARM. Let's make sure everyone is on the same page so that we don't duplicate efforts. I understand that Joel Stanley, Dean McNamee and Lei Zhang have already been doing a lot of work towards that. There's a wiki page there: http://code.google.com/p/chromium/wiki/LinuxChromiumArm I've identified a few missing pieces to get a full version of chrome - there may be others. They are mostly build infrastructure issues: - v8 snapshotting needs to be disabled currently, we'd like to enable it. That means executing mksnapshot as a target executable, either through qemu or directly on device, i.e. the infrastructure to run a target program. Actually the armulator (ARM simulator in V8) can be used to create ARM snapshots without running anything on the target platform. The C++ work is done for this, but the build file work isn't. What is needed is to build mksnapshot.cc with the armulator. This is done with simulator=arm in the scons build. I don't know how it's done with gyp. When the snapshot.cc file has been generated by mksnapshot you need to rebuild V8 from scratch, this time with the cross compiler. With the scons build that would be (after saving snapshot.cc and blowing away the other generated files) with snapshot=nobuild arch=arm wordsize=32. You need to make sure the CXX, AR, RANLIB and CC environment variables point to your cross toolchain. As I say, the build file work for this is not done yet. I am sure that it would be worth doing. The snapshot support makes startup of the VM faster at the cost of a moderate increase in size (moderate for a system capable of running Chromium). Since Chromium starts the VM on every new tab that is worth doing. On the other hand the browser is perfectly usable without this optimization so it is no show-stopper for the ARM version. - Gyp uses pkg-config to find includes/lib dependencies, i.e. it's going to look at the host for them. If your target distribution matches your host maybe you're fine, but it may not work at all, so it'd would be good to extract that and get a way to specify the dependencies explicitly. - The chrome os build relies on the protobuf compiler. The current build system builds it as a target executable, so we either need to run in qemu / on device it as above, or change the build system to understand target vs host executables. I wanted to double check if anyone was working on any of that, or if anyone has good ideas about how to achieve each of them. Please speak up ! Antoine -- Erik Corry, Software Engineer Google Denmark ApS. CVR nr. 28 86 69 84 c/o Philip Partners, 7 Vognmagergade, P.O. Box 2227, DK-1018 Copenhagen K, Denmark. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Halting JS execution in V8?
2009/8/12 Drew Wilson atwil...@chromium.org: Hi all, It appears from looking at the worker code that if worker script enters into an infinite loop, the associated worker thread/process will never exit. The JavaScriptCore implementation uses the JSC timeoutChecker mechanism to halt script execution. Is there an analog we can use for V8? Not yet, but there is a clear need and a design is in place. I didn't see anything that looked particularly likely from a quick browse through the v8 headers, and I also didn't see anything similar for page script in V8Proxy.cpp, so I'm obviously missing something since page script handles infinite loops gracefully. -atw -- Erik Corry, Software Engineer Google Denmark ApS. CVR nr. 28 86 69 84 c/o Philip Partners, 7 Vognmagergade, P.O. Box 2227, DK-1018 Copenhagen K, Denmark. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
