Re: [webkit-dev] jsc bus error EXC_BAD_ACCESS with jsc-only build on Mac

[Michael Saboff via webkit-dev]

7BCFF7431DF6 0x0001a195e000 
> /usr/lib/system/libsystem_malloc.dylib 
> [ 30] F32A2564-6ED1-3DB9-8987-DCF48DBB8BE1 0x0001a6764000 
> /usr/lib/system/libsystem_networkextension.dylib 
> [ 31] C6B67595-08FF-3268-A400-0C0C89F541A8 0x0001a4ddf000 
> /usr/lib/system/libsystem_notify.dylib 
> [ 32] 4593512A-A84B-3D4A-B95A-860679313411 0x0001abd4 
> /usr/lib/system/libsystem_sandbox.dylib 
> [ 33] 09FD13E7-266A-38B8-B797-EA32EDFBFB7F 0x0001ad1b6000 
> /usr/lib/system/libsystem_secinit.dylib 
> [ 34] 3DCD49B9-B3C5-3D90-BE40-A3B807CB9CD7 0x0001a1ad5000 
> /usr/lib/system/libsystem_kernel.dylib 
> [ 35] 4CF75103-429D-3AAE-BA13-2C1F67E47DBB 0x0001a1b4 
> /usr/lib/system/libsystem_platform.dylib 
> [ 36] 9F3B729A-ED04-3E65-ADAC-D75AD06EBBDC 0x0001a1b0f000 
> /usr/lib/system/libsystem_pthread.dylib 
> [ 37] FFDC0C2D-5E65-32F7-B687-99313DD7CCD0 0x0001a7fb9000 
> /usr/lib/system/libsystem_symptoms.dylib 
> [ 38] E71E8D9E-3A87-33E0-B198-31666F5A6FF1 0x0001a18ba000 
> /usr/lib/system/libsystem_trace.dylib 
> [ 39] 3C7E16C5-77E1-3F26-B016-63D485708187 0x0001ad19 
> /usr/lib/system/libunwind.dylib 
> [ 40] 413746C4-9C63-3DC4-A7C4-BBE90CF7D6B3 0x0001a1876000 
> /usr/lib/system/libxpc.dylib 
> [ 41] 871CF1B2-BA2C-385B-8F92-E41F4966C38D 0x0001a1abd000 
> /usr/lib/libc++abi.dylib 
> [ 42] 951F5871-2D10-31AC-999D-7584AD121FA6 0x0001a17a 
> /usr/lib/libobjc.A.dylib 
> [ 43] 01904D2A-57A5-3B53-8751-D6CBCA281FF3 0x0001ad19b000 
> /usr/lib/liboah.dylib 
> [ 44] E2679357-B2AF-30D4-8130-50D31765AF88 0x0001a1a56000 
> /usr/lib/libc++.1.dylib 
> [ 45] AFE750D8-70E2-3DD8-9822-4CD1285CDA39 0x0001a46be000 
> /usr/lib/libicucore.A.dylib 
> 
> Laurence
> 
> On Mar 28, 2023 at 8:13:55 AM, Michael Saboff  <mailto:msab...@apple.com>> wrote:
>> Laurence,
>> 
>> When you try to run the jsc command, are you setting DYLD_FRAMEWORK_PATH to 
>> the location of the built frameworks?  You can either set it and export it 
>> in your shell environment, e.g.
>> 
>>  % export DYLD_FRAMEWORK_PATH=/Users/lrowe/scratch/WebKit/WebKitBuild/Release
>> 
>> Or prepend the setting of it in your command string:
>> 
>>  % DYLD_FRAMEWORK_PATH=/Users/lrowe/scratch/WebKit/WebKitBuild/Release lldb 
>> ./WebKitBuild/Release/bin/jsc
>> 
>> I that doesn’t work, a backtrace at the time of the crash and the output of 
>> the lldb command “image list” would be helpful.
>> 
>> - Michael
>> 
>> 
>>> On Mar 27, 2023, at 11:11 PM, Laurence Rowe via webkit-dev 
>>> mailto:webkit-dev@lists.webkit.org>> wrote:
>>> 
>>> Hi, I’m trying to build jsc on my M1 Mac following the instructions at 
>>> https://trac.webkit.org/wiki/JSCOnly and 
>>> https://webkit.org/getting-started/ . However when I run the built binary 
>>> it exits immediately with a bus error which lldb shows to be EXC_BAD_ACCESS.
>>> 
>>> lrowe@Laurences-MacBook-Air WebKit % git reset --hard origin/main
>>> HEAD is now at b2362a5d6b [UI-side compositing] Safari occasionally crashes 
>>> when scrolling underneath `NSScrollerImpPair` 
>>> https://bugs.webkit.org/show_bug.cgi?id=254484 rdar://107139674
>>> lrowe@Laurences-MacBook-Air WebKit % git clean -Xf
>>> lrowe@Laurences-MacBook-Air WebKit % sudo xcode-select -s 
>>> /Applications/Xcode.app/Contents/Developer
>>> lrowe@Laurences-MacBook-Air WebKit % Tools/Scripts/build-jsc --jsc-only
>>> # build log below
>>> lrowe@Laurences-MacBook-Air WebKit % ./WebKitBuild/Release/bin/jsc 
>>> zsh: bus error  ./WebKitBuild/Release/bin/jsc
>>> 
>>> lrowe@Laurences-MacBook-Air WebKit % lldb ./WebKitBuild/Release/bin/jsc
>>> (lldb) target create "./WebKitBuild/Release/bin/jsc"
>>> Current executable set to 
>>> '/Users/lrowe/scratch/WebKit/WebKitBuild/Release/bin/jsc' (arm64).
>>> (lldb) run
>>> Process 73062 launched: 
>>> '/Users/lrowe/scratch/WebKit/WebKitBuild/Release/bin/jsc' (arm64)
>>> Process 73062 stopped
>>> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS 
>>> (code=2, address=0x10d5ac000)
>>> frame #0: 0x0001a1b43f78 libsystem_platform.dylib`_platform_memmove 
>>> + 168
>>> libsystem_platform.dylib`:
>>> ->  0x1a1b43f78 <+168>: stpq2, q3, [x0]
>>> 0x1a1b43f7c <+172>: subs   x2, x2, #0x40
>>> 0x1a1b43f80 <+176>: b.ls <http://b.ls/>   0x1a1b43f9c   ; 
>>> <+204>
>>> 0x1a1b43f84 <+180>: stp 

Re: [webkit-dev] jsc bus error EXC_BAD_ACCESS with jsc-only build on Mac

[Michael Saboff via webkit-dev]

Laurence,

When you try to run the jsc command, are you setting DYLD_FRAMEWORK_PATH to the 
location of the built frameworks?  You can either set it and export it in your 
shell environment, e.g.

 % export DYLD_FRAMEWORK_PATH=/Users/lrowe/scratch/WebKit/WebKitBuild/Release

Or prepend the setting of it in your command string:

 % DYLD_FRAMEWORK_PATH=/Users/lrowe/scratch/WebKit/WebKitBuild/Release lldb 
./WebKitBuild/Release/bin/jsc

I that doesn’t work, a backtrace at the time of the crash and the output of the 
lldb command “image list” would be helpful.

- Michael


> On Mar 27, 2023, at 11:11 PM, Laurence Rowe via webkit-dev 
>  wrote:
> 
> Hi, I’m trying to build jsc on my M1 Mac following the instructions at 
> https://trac.webkit.org/wiki/JSCOnly and https://webkit.org/getting-started/ 
> . However when I run the built binary it exits immediately with a bus error 
> which lldb shows to be EXC_BAD_ACCESS.
> 
> lrowe@Laurences-MacBook-Air WebKit % git reset --hard origin/main
> HEAD is now at b2362a5d6b [UI-side compositing] Safari occasionally crashes 
> when scrolling underneath `NSScrollerImpPair` 
> https://bugs.webkit.org/show_bug.cgi?id=254484 rdar://107139674
> lrowe@Laurences-MacBook-Air WebKit % git clean -Xf
> lrowe@Laurences-MacBook-Air WebKit % sudo xcode-select -s 
> /Applications/Xcode.app/Contents/Developer
> lrowe@Laurences-MacBook-Air WebKit % Tools/Scripts/build-jsc --jsc-only
> # build log below
> lrowe@Laurences-MacBook-Air WebKit % ./WebKitBuild/Release/bin/jsc 
> zsh: bus error  ./WebKitBuild/Release/bin/jsc
> 
> lrowe@Laurences-MacBook-Air WebKit % lldb ./WebKitBuild/Release/bin/jsc
> (lldb) target create "./WebKitBuild/Release/bin/jsc"
> Current executable set to 
> '/Users/lrowe/scratch/WebKit/WebKitBuild/Release/bin/jsc' (arm64).
> (lldb) run
> Process 73062 launched: 
> '/Users/lrowe/scratch/WebKit/WebKitBuild/Release/bin/jsc' (arm64)
> Process 73062 stopped
> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS 
> (code=2, address=0x10d5ac000)
> frame #0: 0x0001a1b43f78 libsystem_platform.dylib`_platform_memmove + 
> 168
> libsystem_platform.dylib`:
> ->  0x1a1b43f78 <+168>: stpq2, q3, [x0]
> 0x1a1b43f7c <+172>: subs   x2, x2, #0x40
> 0x1a1b43f80 <+176>: b.ls    0x1a1b43f9c   ; 
> <+204>
> 0x1a1b43f84 <+180>: stpq0, q1, [x3]
> Target 0: (jsc) stopped.
> 
> Versions:
> WebKit main (b2362a5d6b)
> Xcode 14.2 (14C18)
> macOS 13.2.1
> CMake.app 3.26.1 (not mentioned at https://webkit.org/build-tools/ but 
> required)
> 
> I’ve also tried variously with Xcode command line tools, homebrew cmake, 
> WebKit tag WebKit-7615.1.26.10.23, and adding the —debug flag to the build 
> but I see the same error.
> 
> Is there anything else I should be doing to build jsc?
> 
> Thanks,
> 
> Laurence Rowe
> 
> 
> # build log
> +  cmake --build /Users/lrowe/scratch/WebKit/WebKitBuild/Release --config 
> Release -- jsc testb3 testair testapi testmasm testdfg -j8
> [  0%] Built target JavaScriptCore_CopyHeaders
> [  1%] Built target JavaScriptCoreSharedScripts
> [  1%] Built target JSCBuiltins
> [  1%] Built target Bytecodes
> [ 35%] Built target WTF_CopyHeaders
> [ 38%] Built target bmalloc_CopyHeaders
> [ 46%] Built target bmalloc
> [ 53%] Built target WTF
> [ 53%] Built target LLIntSettingsExtractor
> [ 53%] Building CXX object 
> Source/JavaScriptCore/CMakeFiles/LLIntOffsetsExtractor.dir/llint/LLIntOffsetsExtractor.cpp.o
> [ 53%] Linking CXX executable ../../bin/LLIntOffsetsExtractor
> [ 53%] Built target LLIntOffsetsExtractor
> [ 53%] Generating ../../JavaScriptCore/DerivedSources/LLIntAssembly.h
> [ 53%] Building CXX object 
> Source/JavaScriptCore/CMakeFiles/LowLevelInterpreterLib.dir/llint/LowLevelInterpreter.cpp.o
> [ 53%] Built target LowLevelInterpreterLib
> [ 53%] Building CXX object 
> Source/JavaScriptCore/CMakeFiles/JavaScriptCore.dir/__/__/JavaScriptCore/DerivedSources/unified-sources/UnifiedSource-f0a787a9-7.cpp.o
> [ 53%] Building CXX object 
> Source/JavaScriptCore/CMakeFiles/JavaScriptCore.dir/__/__/JavaScriptCore/DerivedSources/unified-sources/UnifiedSource-f0a787a9-11.cpp.o
> [ 53%] Building CXX object 
> Source/JavaScriptCore/CMakeFiles/JavaScriptCore.dir/__/__/JavaScriptCore/DerivedSources/unified-sources/UnifiedSource-bfc896e1-4.cpp.o
> [ 53%] Building CXX object 
> Source/JavaScriptCore/CMakeFiles/JavaScriptCore.dir/__/__/JavaScriptCore/DerivedSources/unified-sources/UnifiedSource-bfc896e1-3.cpp.o
> [ 53%] Building CXX object 
> Source/JavaScriptCore/CMakeFiles/JavaScriptCore.dir/__/__/JavaScriptCore/DerivedSources/unified-sources/UnifiedSource-bfc896e1-9.cpp.o
> [ 53%] Building CXX object 
> Source/JavaScriptCore/CMakeFiles/JavaScriptCore.dir/dfg/DFGSpeculativeJIT.cpp.o
> [ 54%] Building CXX object 
> Source/JavaScriptCore/CMakeFiles/JavaScriptCore.dir/dfg/DFGSpeculativeJIT32_64.cpp.o
> [ 54%] Building CXX object 
> Source/JavaScriptCore/CMakeFiles/JavaScriptCore.dir/dfg/DFGSpeculativeJIT64.cp

Re: [webkit-dev] Platform.h vs. makefiles

[Michael Saboff]

> On May 10, 2020, at 11:11 PM, Darin Adler  wrote:
> 
>> On May 10, 2020, at 10:07 PM, Maciej Stachowiak  wrote:
>> 
>> I think the best way to configure WebKit is to use a separate data file, 
>> neither a header nor a makefile or similar, that defines the options in a 
>> single place with clear syntax. Then everything else is generated from that. 
>> Such a system could cover runtime flags as well, which are even more 
>> scattered around the project than compile-time flags.
> 
> Sounds OK. I worry a little about defining yet another language, but 
> otherwise I do find this appealing. Perhaps some people would say that 
> FeatureDefines.props from cmake could be that file?
> 
> Not sure literally a single data file is the best way to do this across 
> multiple platforms/ports. I think PlatformEnableCocoa.h shows us that 
> breaking this down can be helpful.
> 
> One file that has the master list of all the settings, and all the default 
> values. Then other files that contain overlays for each port/configuration 
> where they are different from the default.
> 
> My worry is that it could become complicated, like our TestExpectations 
> files, which were once simple.

One challenge with a data file approach is that all build systems need to be 
aware that it is the root dependency for most targets.  As such I don’t think 
it make sense to invent a new format, but to possibly refine the 
PlatformEnable*.h hierarchy.  Perhaps a new PlatformOverrides.h file that would 
only contain the overrides while the current PlatformEnable*.h contain the 
defaults.

>> Moving logic from build files to the header is probably a move in the right 
>> direction, though of course it carries risk, particularly for less tested 
>> configurations.
> 
> Yes, I’m not suggesting rushing to do it all at once in a mass change.
> 
> But for new things especially on Apple’s Cocoa platforms, I’d like to avoid 
> FeatureDefines.xcconfig and see new things in the PlatformEnableCocoa.h 
> header file instead. Unless the defines need to affect the build system and 
> not just the C++ code, I think the header file is superior.
> 
> — Darin
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

- Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Offline Assembler build step always computes hashes even when nothing changes

[Michael Saboff]

Darin,

I can take a look at this.

Filed > “Offline assembler always 
computes hashes even when nothing changes"

- Michael

> On Sep 16, 2018, at 4:03 PM, Darin Adler  > wrote:
> 
> I noticed that the “Offline Assembler” build step was taking between 5 and 30 
> seconds every time I build. Really stands out in incremental builds. I 
> realized that this step does not do any dependency analysis. Every time, it 
> builds a hash of the input to see if it needs to recompute the assembly.
> 
> That’s probably not the best pattern; normally we like to use file 
> modification dates to avoid doing any work when files haven’t changed.
> 
> Is there someone who can help me fix this so we get faster incremental builds?
> 
> — Darin
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org 
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [jsc-dev] Question about ARMv7 JIT maintenance by Apple

[Michael Saboff]

Yusuke,

What are the deficiencies you see in the current ARMv7 disassembler?

- Michael

> On May 4, 2018, at 7:45 PM, Yusuke SUZUKI  > wrote:
> 
> On Sat, May 5, 2018 at 11:27 AM Filip Pizlo  > wrote:
> We aren’t maintaining armv7. 
> 
> OK, thanks. I'll replace ARMv7 disassembler with capstone based one once 
> capstone is adopted :)
> 
>  
> 
> -Filip
> 
> > On May 4, 2018, at 7:01 PM, Yusuke SUZUKI  > > wrote:
> > 
> > Hi WebKittens,
> > 
> > JSC has X86, X86_64, ARM64, ARM, ARMv7, and MIPS JIT architectures.
> > While X86, X86_64, and ARM64 is maintained by build bots configured by 
> > Apple,
> > the other architectures are maintained by the community.
> > 
> > Recently, I'm about to adopting capstone disassembler for MIPS and ARM.
> > And I'm also wondering if ARMv7 can use it instead of our own disassembler.
> > 
> > So my question is, is ARMv7 JIT maintained by Apple right now? Or is it 
> > maintained by the community?
> > If Apple does not maintain it right now, I would like to drop ARMv7 
> > disassembler and use capstone instead.
> > 
> > Best regards,
> > Yusuke Suzuki
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org 
> > https://lists.webkit.org/mailman/listinfo/webkit-dev 
> > 
> ___
> jsc-dev mailing list
> jsc-...@lists.webkit.org 
> https://lists.webkit.org/mailman/listinfo/jsc-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Proposal: Do not support Windows fibers

[Michael Saboff]

Here is the reply from iTunes for the WebKit-Dev list

- Michael

——

From an iTunes perspective, WebKit can eliminate any remaining Windows Fiber 
API support.

iTunes still uses some cooperative threading, but implements its own mechanism 
on top of regular preemptive Windows threads. And we believe we've fixed all 
occurrences of calling WebKit/JSC from our non-main cooperative threads.

- John

> On Dec 5, 2017, at 10:26 AM, Michael Saboff  wrote:
> 
> [Bringing John Lehner from the iTunes team into the discussion]
> 
> Last I knew, the iTunes team uses fibers.  IIRC, the thread they use to call 
> into WebKit/JSC only has one fiber, other parts of the app use multiple 
> fibers on one thread but don’t have JS objects active in those threads / 
> fibers.
> 
> John, have things changed for iTunes on Windows such that we can eliminate 
> support for fibers?
> 
> - Michael
> 
>> On Dec 5, 2017, at 10:16 AM, Ryosuke Niwa > <mailto:rn...@webkit.org>> wrote:
>> 
>> Yeah, I don't think there is much need to support fibers. With features like 
>> web workers, supporting fibers doesn't make much sense.
>> 
>> - R. Niwa
>> 
>> On Tue, Dec 5, 2017 at 9:44 AM, Yusuke SUZUKI > <mailto:utatane@gmail.com>> wrote:
>> Hi, Webkittens,
>> 
>> I would like to make sure OR declare that WebKit does not support Windows 
>> fibers.
>> While fiber related functions are used in WTF, I believe that it is because 
>> fiber local storage (FLS) can have destructors. And it is not intended to 
>> support fibers explicitly.
>> 
>> Actually, I believe the current WebKit does not work well with Windows 
>> fibers right now.
>> For example, our JSC GC is conservative for stack and registers. It means 
>> that GC needs to scan stack and registers to gather conservative roots. But 
>> if your fiber is not executed at that time, JSC GC will miss to scan the 
>> stack and registers of those inactive fibers. As a result, managed objects 
>> will be collected if it is only referenced from the roots in the inactive 
>> fibers.
>> 
>> And I think we can potentially improve performance of our TLS by using 
>> thread_local implementation in VC++ instead of using FLS. FLS is slow and it 
>> causes some problems[1]. I'm not sure the performance characteristics and 
>> implementation details of thread_local in VC++, but it's worth checking.
>> 
>> So, I think we should not support Windows fibers. I would like to hear 
>> opinions about it.
>> 
>> [1]: https://bugs.webkit.org/show_bug.cgi?id=146448 
>> <https://bugs.webkit.org/show_bug.cgi?id=146448>
>> 
>> Best regards,
>> Yusuke Suzuki
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
>> https://lists.webkit.org/mailman/listinfo/webkit-dev 
>> <https://lists.webkit.org/mailman/listinfo/webkit-dev>
>> 
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Proposal: Do not support Windows fibers

[Michael Saboff]

[Bringing John Lehner from the iTunes team into the discussion]

Last I knew, the iTunes team uses fibers.  IIRC, the thread they use to call 
into WebKit/JSC only has one fiber, other parts of the app use multiple fibers 
on one thread but don’t have JS objects active in those threads / fibers.

John, have things changed for iTunes on Windows such that we can eliminate 
support for fibers?

- Michael

> On Dec 5, 2017, at 10:16 AM, Ryosuke Niwa  wrote:
> 
> Yeah, I don't think there is much need to support fibers. With features like 
> web workers, supporting fibers doesn't make much sense.
> 
> - R. Niwa
> 
> On Tue, Dec 5, 2017 at 9:44 AM, Yusuke SUZUKI  > wrote:
> Hi, Webkittens,
> 
> I would like to make sure OR declare that WebKit does not support Windows 
> fibers.
> While fiber related functions are used in WTF, I believe that it is because 
> fiber local storage (FLS) can have destructors. And it is not intended to 
> support fibers explicitly.
> 
> Actually, I believe the current WebKit does not work well with Windows fibers 
> right now.
> For example, our JSC GC is conservative for stack and registers. It means 
> that GC needs to scan stack and registers to gather conservative roots. But 
> if your fiber is not executed at that time, JSC GC will miss to scan the 
> stack and registers of those inactive fibers. As a result, managed objects 
> will be collected if it is only referenced from the roots in the inactive 
> fibers.
> 
> And I think we can potentially improve performance of our TLS by using 
> thread_local implementation in VC++ instead of using FLS. FLS is slow and it 
> causes some problems[1]. I'm not sure the performance characteristics and 
> implementation details of thread_local in VC++, but it's worth checking.
> 
> So, I think we should not support Windows fibers. I would like to hear 
> opinions about it.
> 
> [1]: https://bugs.webkit.org/show_bug.cgi?id=146448 
> 
> 
> Best regards,
> Yusuke Suzuki
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org 
> https://lists.webkit.org/mailman/listinfo/webkit-dev 
> 
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Building WebKit for an iOS device

[Michael Saboff]

I’ll add a little to Alex’s comments.

I doubt you could build all of WebKit with the public iOS SDK.  You certainly 
can’t sign JavaScriptCore to use JIT memory.  Even if could build WebKit and 
statically linked your code with what you built, there will likely be some 
mismatch between the WebKit you built and the System frameworks that WebKit 
links against, such as UIKit, that will cause your app to crash on startup.

- Michael

> On Jul 12, 2017, at 10:19 AM, Alex Christensen  wrote:
> 
> WebKit can be built and run on the iOS simulator by anyone with the public 
> iOS SDK.  I use 
> https://webkit.org/blog/3457/building-webkit-for-ios-simulator/ 
>  when I 
> forget how to do this.
> 
> I guess WebKit can be built for device, but I’m pretty sure WebKit cannot be 
> put as the system framework on an iOS device without Apple-internal tools.  
> With a lot of work you might be able to statically link everything into a 
> custom app for local debugging, but I’m pretty sure such an app would be 
> rejected by the App Store based on section 2.5.6 of 
> https://developer.apple.com/app-store/review/guidelines/ 
> 
> 
>> On Jul 12, 2017, at 8:31 AM, Frédéric WANG > > wrote:
>> 
>> Hello,
>> 
>> For development and testing purpose, I was wondering if there is a way
>> to produce a build of WebKit/Safari-mobile and to install it on a device
>> (instead of using the iOS simulator)? And is there any specific
>> requirement like having an Apple developer license and a registered device?
>> 
>> I know that we have a builder [1] and I just noticed the "--ios-device"
>> parameter for the build-webkit script but I can't find any information
>> on the official documentation [2] or on the WebKit wiki. I also tried
>> searching this mailing list about the topic but could not find any
>> relevant thread.
>> 
>> Thanks,
>> 
>> Frédéric
>> 
>> [1] https://build.webkit.org/builders/Apple%20iOS%2010%20Release%20(Build) 
>> 
>> [2] https://webkit.org/building-webkit/ 
>> 
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org 
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Saam Barati is now a reviewer

[Michael Saboff]

Congratulations Saam.

I see you already r+’ed a patch!

- Michael

> On Aug 4, 2015, at 11:48 AM, Filip Pizlo  wrote:
> 
> Congrats Saam!
> 
> -Filip
> 
> 
>> On Aug 4, 2015, at 11:47 AM, Mark Lam  wrote:
>> 
>> You may have seen my commit making this so, but just to make it official ...
>> 
>> Hi everyone,
>> 
>> Just want to announce that Saam Barati is now a reviewer.  You can now bug 
>> him for reviews. =)
>> 
>> Mark
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Stack Alignment error in LLINT

[Michael Saboff]

Rodney,

The “align the stack” code for 32 bit platforms is found in 
Source/JavaScriptCore/llint/LowLevelInterpreter32_64.asm 
(http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/llint/LowLevelInterpreter32_64.asm)
 beginning at line 218.  There isn’t an if / elsif for Linux or QNX.  This 
stack aligning code is at the top of the code that I think is generating your 
SIGTRAP.  Unfortunately I don’t think that the offline assembler that 
“assembles” the LLINT code has an OS specific type for X86 QNX.  You can try 
locally in your build adding “or X86” to the end of the “if X86_WIN” to see if 
that takes care of your issue.

It would also be interesting to know if Linux build with exceptions has the 
problem as well.

- Michael

> On Jul 27, 2015, at 8:50 AM, Rodney Dowdall  
> wrote:
> 
> Thanks for the response Michael.  Where does the code that does the padding 
> live?  It may be that I need to add something in there.  I can try changing 
> what the stack alignment should be, but from what I understand the QNX OS 
> should align to 16.  Maybe it is the exceptions that are causing the problem. 
>  I could try building a 32 bit Linux build with exceptions on to see if I get 
> the same problem.
> 
> Regards,
> Rodney
> 
> On 07/27/2015 11:24 AM, Michael Saboff wrote:
>> Rodney,
>> 
>> JavaScriptCore assumes that the stack is 16 byte aligned.  This may be more 
>> restrictive than some OS / ABIs, but there is code to pad appropriately for 
>> some platforms. You didn’t say what OS you are running on, but maybe there 
>> needs to be a code added for your OS.  Turning on C++ exceptions could be 
>> responsible, as that could be changing stack layout.  I don’t know of any 
>> platform that turns on C++ exceptions, so you may be in uncharted waters.
>> 
>> Your build is 2 months old, the current revision is 187434.  You could also 
>> try a more recent build.
>> 
>> - Michael
>> 
>>> On Jul 27, 2015, at 8:07 AM, Rodney Dowdall  
>>> wrote:
>>> 
>>> Hello
>>> 
>>> I am seeing a SIGTRAP generated in the LLINT code when I try and load up a 
>>> page.  It happens as soon as the page tries to execute JavaScript.  The 
>>> target is an 32 bit x86 machine.  The SIGTRAP appears to happen when it is 
>>> checking the stack alignment.  I have tried compiling the code with the gcc 
>>> option -mstackrealign and without it.  The SIGTRAP is generated in the same 
>>> spot with or without the option.  C++ exceptions are turned on (they have 
>>> to be with this particular compiler.  The compiler is gcc based).  The 
>>> version of Webkit that I am building from is 184845.
>>> 
>>> 
>>> Here is the assembly execution that causes the SIGTRAP:
>>> 
>>>  vmEntryToJavaScript:
>>> b9a80ef7:   push %ebp
>>> b9a80ef8:   mov %esp,%ebp
>>> b9a80efa:   push %esi
>>> b9a80efb:   push %edi
>>> b9a80efc:   push %ebx
>>> b9a80efd:   mov 0xc(%ebp),%ebx
>>> b9a80f00:   mov 0x8(%ebp),%edi
>>> b9a80f03:   mov %ebp,%esp
>>> b9a80f05:   sub $0x20,%esp
>>> b9a80f08:   mov %ebx,(%esp)
>>> b9a80f0b:   mov 0x1498(%ebx),%edx
>>> b9a80f11:   mov %edx,0x4(%esp)
>>> b9a80f15:   mov 0x1494(%ebx),%edx
>>> b9a80f1b:   mov %edx,0x8(%esp)
>>> b9a80f1f:   mov 0x10(%ebp),%esi
>>> b9a80f22:   mov 0x20(%esi),%edx
>>> b9a80f25:   add $0x4,%edx
>>> b9a80f28:   shl $0x3,%edx
>>> b9a80f2b:   mov %esp,%eax
>>> b9a80f2d:   sub %edx,%eax
>>> b9a80f2f:   cmp 0x2384(%ebx),%eax
>>> b9a80f35:   jae 0xb9a80f71 
>>> 
>>> b9a80f71:   mov %eax,%esp
>>> b9a80f73:   mov $0x4,%eax
>>> b9a80f78:   sub $0x1,%eax
>>> b9a80f7b:   mov 0x4(%esi,%eax,8),%ecx
>>> b9a80f7f:   mov %ecx,0xc(%esp,%eax,8)
>>> b9a80f83:   mov (%esi,%eax,8),%ecx
>>> b9a80f86:   mov %ecx,0x8(%esp,%eax,8)
>>> b9a80f8a:   test %eax,%eax
>>> b9a80f8c:   jne 0xb9a80f78 
>>> 
>>> b9a80f9e:   sub $0x1,%ecx
>>> b9a80fa1:   movl $0xfffc,0x2c(%esp,%ecx,8)
>>> b9a80fa9:   movl $0x0,0x28(%esp,%ecx,8)
>>> b9a80fb1:   cmp %ecx,%edx
>>> b9a80fb3:   jne 0xb9a80f9e 
>>> b9a80fb5:   mov 0x28(%esi),%eax
>>> b9a80fb8:   test %edx,%edx
>>> b9a80fba:   je 0xb9a80fd0 
>>> 
>>> b9a80f78:   sub $0x1,%eax
>>> b9a80f7b:   mov 0x4(%esi,%eax,8),%ecx
>>> b9a80f7f:   mov %ecx,0xc(%esp,%eax,8)
>>> b9a80f83:   mov (%esi,%eax,8),%ecx
>>> b9a80f86:   mov %ecx,0x8(%esp,%eax,8)
>>> b9a80f8a:   test %eax,%eax

Re: [webkit-dev] Stack Alignment error in LLINT

[Michael Saboff]

Rodney,

JavaScriptCore assumes that the stack is 16 byte aligned.  This may be more 
restrictive than some OS / ABIs, but there is code to pad appropriately for 
some platforms. You didn’t say what OS you are running on, but maybe there 
needs to be a code added for your OS.  Turning on C++ exceptions could be 
responsible, as that could be changing stack layout.  I don’t know of any 
platform that turns on C++ exceptions, so you may be in uncharted waters.

Your build is 2 months old, the current revision is 187434.  You could also try 
a more recent build.

- Michael

> On Jul 27, 2015, at 8:07 AM, Rodney Dowdall  
> wrote:
> 
> Hello
> 
> I am seeing a SIGTRAP generated in the LLINT code when I try and load up a 
> page.  It happens as soon as the page tries to execute JavaScript.  The 
> target is an 32 bit x86 machine.  The SIGTRAP appears to happen when it is 
> checking the stack alignment.  I have tried compiling the code with the gcc 
> option -mstackrealign and without it.  The SIGTRAP is generated in the same 
> spot with or without the option.  C++ exceptions are turned on (they have to 
> be with this particular compiler.  The compiler is gcc based).  The version 
> of Webkit that I am building from is 184845.
> 
> 
> Here is the assembly execution that causes the SIGTRAP:
> 
>  vmEntryToJavaScript:
> b9a80ef7:   push %ebp
> b9a80ef8:   mov %esp,%ebp
> b9a80efa:   push %esi
> b9a80efb:   push %edi
> b9a80efc:   push %ebx
> b9a80efd:   mov 0xc(%ebp),%ebx
> b9a80f00:   mov 0x8(%ebp),%edi
> b9a80f03:   mov %ebp,%esp
> b9a80f05:   sub $0x20,%esp
> b9a80f08:   mov %ebx,(%esp)
> b9a80f0b:   mov 0x1498(%ebx),%edx
> b9a80f11:   mov %edx,0x4(%esp)
> b9a80f15:   mov 0x1494(%ebx),%edx
> b9a80f1b:   mov %edx,0x8(%esp)
> b9a80f1f:   mov 0x10(%ebp),%esi
> b9a80f22:   mov 0x20(%esi),%edx
> b9a80f25:   add $0x4,%edx
> b9a80f28:   shl $0x3,%edx
> b9a80f2b:   mov %esp,%eax
> b9a80f2d:   sub %edx,%eax
> b9a80f2f:   cmp 0x2384(%ebx),%eax
> b9a80f35:   jae 0xb9a80f71 
> 
> b9a80f71:   mov %eax,%esp
> b9a80f73:   mov $0x4,%eax
> b9a80f78:   sub $0x1,%eax
> b9a80f7b:   mov 0x4(%esi,%eax,8),%ecx
> b9a80f7f:   mov %ecx,0xc(%esp,%eax,8)
> b9a80f83:   mov (%esi,%eax,8),%ecx
> b9a80f86:   mov %ecx,0x8(%esp,%eax,8)
> b9a80f8a:   test %eax,%eax
> b9a80f8c:   jne 0xb9a80f78 
> 
> b9a80f9e:   sub $0x1,%ecx
> b9a80fa1:   movl $0xfffc,0x2c(%esp,%ecx,8)
> b9a80fa9:   movl $0x0,0x28(%esp,%ecx,8)
> b9a80fb1:   cmp %ecx,%edx
> b9a80fb3:   jne 0xb9a80f9e 
> b9a80fb5:   mov 0x28(%esi),%eax
> b9a80fb8:   test %edx,%edx
> b9a80fba:   je 0xb9a80fd0 
> 
> b9a80f78:   sub $0x1,%eax
> b9a80f7b:   mov 0x4(%esi,%eax,8),%ecx
> b9a80f7f:   mov %ecx,0xc(%esp,%eax,8)
> b9a80f83:   mov (%esi,%eax,8),%ecx
> b9a80f86:   mov %ecx,0x8(%esp,%eax,8)
> b9a80f8a:   test %eax,%eax
> b9a80f8c:   jne 0xb9a80f78 
> 
> b9a80f78:   sub $0x1,%eax
> b9a80f7b:   mov 0x4(%esi,%eax,8),%ecx
> b9a80f7f:   mov %ecx,0xc(%esp,%eax,8)
> b9a80f83:   mov (%esi,%eax,8),%ecx
> b9a80f86:   mov %ecx,0x8(%esp,%eax,8)
> b9a80f8a:   test %eax,%eax
> b9a80f8c:   jne 0xb9a80f78 
> 
> b9a80f78:   sub $0x1,%eax
> b9a80f7b:   mov 0x4(%esi,%eax,8),%ecx
> b9a80f7f:   mov %ecx,0xc(%esp,%eax,8)
> b9a80f83:   mov (%esi,%eax,8),%ecx
> b9a80f86:   mov %ecx,0x8(%esp,%eax,8)
> b9a80f8a:   test %eax,%eax
> b9a80f8c:   jne 0xb9a80f78 
> b9a80f8e:   mov 0x10(%esi),%edx
> b9a80f91:   sub $0x1,%edx
> b9a80f94:   mov 0x20(%esi),%ecx
> b9a80f97:   sub $0x1,%ecx
> b9a80f9a:   cmp %ecx,%edx
> b9a80f9c:   je 0xb9a80fb5 
> 
> b9a80fd0:   mov %esp,0x1498(%ebx)
> b9a80fd6:   mov %ebp,0x1494(%ebx)
> b9a80fdc:   add $0x8,%esp
> b9a80fdf:   mov %esp,%ecx
> b9a80fe1:   and $0xf,%ecx
> b9a80fe4:   test %ecx,%ecx
> b9a80fe6:   je 0xb9a80fee 
> b9a80fe8:   mov $0xbad0dc02,%ecx
> b9a80fed:   int3
> 
> So using the LLintAssembly.h I tracked this too:
> 
>"\tjz " 
> LOCAL_LABEL_STRING(_offlineasm_doVMEntry__makeCall__checkStackPointerAlignment__stackPointerOkay
> 
> Which leads me to believe that the alignment on my stack is wrong. The value 
> of esp is 0x7db9284.  The value of ecx after the and is 4, so that looks 
> right.
> 
> I don't have a lot of experience with the LLINT, so I was wondering if there 
> was a specific place I should start to look to see why this error is beign 
> generated.
> 
> Thanks,
> Rodney
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Tagged assertions...

[Michael Saboff]

This will add a step that developers will have to remember when changing an 
ASSERT.  There may be developers that want to knowingly keep the same tag.  
What about creating my own tag values?  How will we guard against reusing a tag?

So what would be an appropriate tag for an ASSERT in a templated class that is 
in a .h file?  An example would be the at() method in Vector.h:
T& at(Checked i)
{
RELEASE_ASSERT(i < size());
return Base::buffer()[i];
}
I question having hundreds of ASSERTs in the code all with the same tag 
provides any benefit.  These identically tagged ASSERTs are for guarding 
against unrelated out-of-bounds access checks.

If you say that we aren’t going to handle RELEASE_ASSERTs, these are the 
asserts that developers have said are the most important, in that we want to 
assert in a production build.  In fact you might have an argument for tagging 
RELEASE_ASSERTs if we think it would improve debugging post release crashes.

- Michael

> On Nov 6, 2014, at 12:34 PM, Said Abou-Hallawa  wrote:
> 
> When the logical expression in the ASSERT is changed, you should do the 
> following:
> 
> -   ASSERT_TAG(condition, “abcde”);
> +  ASSERT(new_condition);
> 
> Then the pre-build tagging tool will generate a new tag for the new assertion:
> 
> +  ASSERT(new_condition, “fghij”);
> 
> So the assertions do not get messed up with Bugzailla.
> 
> The pre-build tool runs periodically only on Bot, maybe once every day and 
> only on the touched files since it was last run.  Then it commits only the 
> changed files because of tagging.  This should not add much to the build 
> process.
> 
> Both ASSERT and ASSERT_TAG should be supported.  Since the developer should 
> only add ASSERT and leave the tagging for the pre-build tagging tool.
> 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Tagged assertions...

[Michael Saboff]

So what happens to the tag when the logical expression in the ASSERT is 
changed?  Does this generate a new tag?

For me, the filename, function, line number and ASSERT expression are 
sufficient almost all the time to identify the relevant ASSERT.

I have concerns that creating the tags and associated db will add complexity to 
the code and our build time and will provide little value.

- Michael


> On Nov 6, 2014, at 11:44 AM, Said Abou-Hallawa  wrote:
> 
> The function name and the line number may change if the code changes.   A 
> unique tag associated with the assertion should stay the same.  So when you 
> want to search for the assertion, you just need the tag since it is unique.  
> We can even extend the dump to do the search in Bugzilla as well.  So if the 
> assertion fires, the dump might look like the following:
> 
>   ASSERTION FAILED (tag: abcde) condition
> Bug 12345 (closed): ASSERTION failed in someFunction
> Bug 67890 (open): Still ASSERTION failed in someFunction
>   … rest of the call-stack
> 
> So you do not even need to search Bugzilla for it.  You would know 
> immediately that the assertion is being tracked by an opened bug.
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Using OfflineAsm

[Michael Saboff]

Christopher,

Let me add a little to Phil’s comments.

As Phil says, you shouldn’t expect much if any performance gain going from the 
C LOOP to one of the assembler back ends if you also don’t plan on enabling 
JITs.

The architectures / OS combinations that work with the LLInt is nearly the same 
as what is supported by the baseline JIT.  Basically X86 (32 & 64), ARM 
(traditional, thumb2 and 64) and to a lessor degree MIPS and SH4.  These work 
as appropriate on Mac OS X, Windows, Linux, iOS and a couple other OSes.  If 
you have a processor and/or OS, or combination of the two that is not 
supported, it will likely require work in the offline assembler and / or LLInt 
code for it to work.  The effort is probably won’t payoff unless you plan on 
eventually supporting one or more of the JITs.

What processor(s) and OS(es) are you targeting?

- Michael

On Sep 5, 2014, at 3:47 PM, Filip Pizlo  wrote:

> 
> 
> On Sep 5, 2014, at 3:23 PM, "Vienneau, Christopher"  wrote:
> 
>> Hello,
>>  
>> I’m looking for some information about the Java script interpreter ASM 
>> backend, aka OfflineAsm.  
>>  
>> First a bit of background information; the code I have been using is about a 
>> year old, on several platforms we don’t run with JIT and won’t be able to 
>> enable it.  This means that we’ve been using the LLINT_C_LOOP path in these 
>> cases.  It was considered that the ASM backend may be able to improve 
>> performance in this case, currently I’m taking a look at how things are done 
>> in a more recent snapshot of the trunk to be sure this development effort 
>> will be going in the right direction on what is done there.  As a side note 
>> I see that LLINT_C_LOOP has been replaced with #if !ENABLE(JIT) which I 
>> guess is pretty much how it has always behaved.
>>  
>> So my questions are:
>> 1)  How is the ASM backend intended to be used?
> 
> As a bottom tier for a mixed mode execution VM. We compile to assembly to be 
> able to get an ABI that is compatible with our JITs and to be able to do OSR. 
> 
>> Is there a doc that covers this?
> 
> No. 
> 
>> 2)  Can I essentially move from the “C LOOP” to neither “C LOOP” nor 
>> “JIT”? or is the ASM backend dependent on JIT itself?  
> 
> You should be able to use the asm backend without the JIT. We do this if we 
> compiled with the JIT but we failed to allocate writable+executable memory at 
> run time. With some hacks you could probably compile webkit to always do 
> this. 
> 
>> It appears this would be handled by the defines in 
>> Source\JavaScriptCore\llint\LLIntOfflineAsmConfig.h
>> 3)  If JIT is expected to use the ASM backend is there a way this can be 
>> worked around?
> 
> The JIT doesn't use offlineasm.
> 
>> 4)  Should I actually expect a performance increase compared to the “C 
>> LOOP”?
> 
> Not really, unless your C compiler sucks. 
> 
>> 5)  Are there any other suggestions on how to improve performance of 
>> Java script code in a non-JIT port?
> 
> Not really but contributions are welcome. 
> 
>>  
>> Thanks for any feedback
>>  
>> Chris Vienneau
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] lldb scripted command for JavaScript backtrace

[Michael Saboff]

A new python scripted javascript backtrace command and supporting C++ code now 
exists starting with change set r170432.  This is only for lldb and may be 
replaced in the future when a JIT interface is made available for lldb.  The 
new command is btjs and it can take an optional frame count, just like the bt 
command.  To use the new JavaScript enabled backtrace, import 
Tools/lldb/lldb_webkit.py with the command:
(lldb) command script import ../OpenSource/Tools/lldb/lldb_webkit.py
You can make bt an alias to btjs with the lldb command:
(lldb) command alias bt btjs
These commands can be added to your ~/.lldbinit file so they are available for 
every lldb session.

Here is a comparison of the builtin “bt” with the scripted “btjs”:

(lldb) bt
* thread #1: tid = 0x18b67e, 0x0001004df3b4 
JavaScriptCore`JSC::genericUnwind(vm=0x00010280, 
callFrame=0x7fff5fbfdf00, exceptionValue=JSValue at 0x7fff5fbfde68) + 
20 at JITExceptions.cpp:45, queue = 'com.apple.main-thread, stop reason = 
breakpoint 1.1
frame #0: 0x0001004df3b4 
JavaScriptCore`JSC::genericUnwind(vm=0x00010280, 
callFrame=0x7fff5fbfdf00, exceptionValue=JSValue at 0x7fff5fbfde68) + 
20 at JITExceptions.cpp:45
frame #1: 0x00010063c35a 
JavaScriptCore`llint_slow_path_handle_exception(exec=0x7fff5fbfdf00, 
pc=0x000101e00100) + 170 at LLIntSlowPaths.cpp:1390
frame #2: 0x000100645d77 JavaScriptCore`llint_entry + 18661
frame #3: 0x2cbc7c804595
frame #4: 0x000100647a4f JavaScriptCore`llint_entry + 26045
frame #5: 0x00010064122a JavaScriptCore`callToJavaScript + 346

(lldb) btjs
* thread #1: tid = 0x18b67e, 0x0001004df3b4, queue = 
'com.apple.main-thread, stop reason = breakpoint 1.1
frame #0: 0x0001004df3b4 
JavaScriptCore`JSC::genericUnwind(vm=0x00010280, 
callFrame=0x7fff5fbfdf00, exceptionValue=JSValue at 0x7fff5fbfde68) + 
20 at JITExceptions.cpp:45
frame #1: 0x00010063c35a 
JavaScriptCore`llint_slow_path_handle_exception(exec=0x7fff5fbfdf00, 
pc=0x000101e00100) + 170 at LLIntSlowPaths.cpp:1390
frame #2: 0x000100645d77 #BXj6qv [LLInt](Undefined)
frame #3: 0x2cbc7c804595 bar#DHjEHv [DFG](Cell[global ID: 359]: 
0x1030df970, Cell[Function ID: 36]: 0x1033b94b0)
frame #4: 0x000100647a4f #BMvYzp [LLInt](Cell[JSProxy ID: 322]: 
0x1030ffb90)
frame #5: 0x00010064122a JavaScriptCore`callToJavaScript + 346

- Michael___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Merging back the jsCStack branch

[Michael Saboff]

The branch has been merged back to trunk in change set r163027: 
.

- Michael

On Jan 27, 2014, at 6:00 PM, mhahnenb...@apple.com wrote:

> Hello WebKitters,
> 
> The JavaScriptCore team is planning on merging back our temporary development 
> branch (at http://trac.webkit.org/browser/branches/jsCStack) that we’ve been 
> working on for the past couple of months.
> 
> The primary features that this branch will bring to trunk are:
> 
> (1) JavaScript code in JavaScriptCore now runs exclusively on the C stack. 
> Previously JavaScriptCore made use of the C stack only for calls into its C++ 
> runtime, and it used a separate custom stack data structure for execution of 
> compiled JavaScript code. Now it’s all C stack all the time. This work was 
> primarily in support of the next feature...
> 
> (2) More FTL goodness. The FTL already existed in trunk, but the most recent 
> bleeding edge work has been done on the branch since that work depended on 
> the other C-stack-related work. It will still be behind #ifdefs, and it won’t 
> be compiled by default.
> 
> The plan is to merge back early tomorrow morning so that if there are any 
> major issues they won’t cause any significant impact. I’ll be available via 
> IRC and email to help with any problems. Let me know if this plan doesn’t 
> work for you.
> 
> Thanks!
> -Mark
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] JavaScriptCore Merge of C Stack Work

[Michael Saboff]

The JavaScriptCore team at Apple has been doing work on a branch 
(http://svn.webkit.org/repository/webkit/branches/jsCStack) to move JavaScript 
processing to use the native C stack for all engines (LLInt, Baseline JIT, DFG 
JIT, and the new FTL JIT).  We are in the end stages of merging the work of 
that branch to trunk (tracked in 
https://bugs.webkit.org/show_bug.cgi?id=127763).  When this merge is complete 
and the patch is landed, ports that use the LLInt and/or any JIT will use the 
native call-return stack to make calls to/from JavaScript.  The LLINT C-Loop 
will be the only code that uses the separate JSStack, and only while in the 
C-Loop.

We are relying on the EWS bots to test ports that we can’t test directly.  
There are some ports where there aren’t any EWS bots (SH4 and MIPS).  Although 
we have made what we think are the correct changes for all ports, the changes 
for those we can’t test are speculative at best.

Obviously, if there are any issues we will support the work of others to get 
the ports they support working.

- Michael Saboff

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] When to use "auto"? (I usually consider it harmful)

[Michael Saboff]

On Jan 3, 2014, at 11:28 AM, Geoffrey Garen  wrote:

>> However I also feel the "harm" here is debatable enough that people working 
>> on/reviewing the code should make decisions instead of there being a project 
>> level dictate. It is a new thing, the appropriate usage hasn't yet settled 
>> and people should be allowed to experiment.
> 
> The experiment has been going on for some time now. We have over 1000 unique 
> uses of “auto” in the codebase. I think it’s time to clarify and collect what 
> we’ve learned.
> 
> One reason I’m eager to produce a guideline is the patches I’ve seen Andreas 
> writing. A whole new kind of pointer in one of the most error-prone pointer 
> areas of our codebase (as measured by security exploits) deserves a clear 
> guideline for readability and understandability.
> 
> Note that a coding style guideline does not prevent reviewers from exercising 
> good judgement — either by accepting or rejecting an edge case, or by 
> proposing a modification to the guidelines. 
> 
>> I'm not sure how much rules we really need beyond "use 'auto' when it 
>> improves code". I gather from this thread that especially people working on 
>> JSC are not comfortable using it so they shouldn’t.
> 
> I strongly object to varying coding style arbitrarily based on author or 
> project file. That's a recipe for an unreadable polyglot codebase.
> 
> It’s very common for WebKit engineers to work across different pieces of the 
> engine, and that is a strength in our project that I’d like to preserve and 
> extend.
> 
>> If we start making rules I'd add the following:
>> 
>> - Use "auto" when the type name is already mentioned on a line:
> 
> Agreed.
> 
>> auto& cell = toRenderTableCell(*renderer); // right
>> RenderTableCell& cell = toRenderTableCell(*renderer);  // wrong
> 
> Not sure.
> 
> These lines of code do not include a verbatim type name, and so they are not 
> friendly to cmd-click/select-and-search. Changing the function signature to 
> “to”, or something like that, might help.
> 
> There seems to be consensus that “auto& cell = 
> *static_cast(renderer)” would be correct — setting aside 
> the fact that we usually don’t cast like that in the render tree.
> 
>> for (auto& source : descendantsOfType(*this)) // right
>> for (const HTMLSourceElement& source : 
>> descendantsOfType(*this)) // wrong
> 
> OK.
> 
>> auto properties = std::make_unique();  //right
>> std::unique_ptr properties = 
>> std::make_unique(); //wrong
> 
> OK.
> 
>> This rule is already widely deployed and I think the code readability has 
>> improved.
> 
> Agreed. I especially liked reading "auto buffer = 
> std::make_unique(length)” when I found it. It’s a shame that mutex 
> types and other unmovable types can’t work this way.
> 
>> - Use "auto" when the type is irrelevant. This covers things like iterators 
>> and adapter classes:
>> 
>> auto sourceDescendants = descendantsOfType(*this));
> 
> I’m not sure what you mean by type being irrelevant. I’d want to make a list 
> of examples where we think type is or is not relevant.
> 
> For example, one could argue that type is irrelevant for any pointer-style 
> class, since you just use “->” and “*”, which work for any pointer-style 
> classes, and the name conveys the interface. But I disagree. The pointer type 
> conveys the lifetime and passing semantics, and those are essential, and need 
> to be called out.
> 
>> - Use "auto" when type is obvious for people with basic familiarity with a 
>> subsystem:
>> 
>> auto& style = renderer.style();
> 
> I don’t like this. I want code to be clear even to folks who are not super 
> familiar.
> 
> For example, recently, Michael had to fix a buffer overrun bug in low-level 
> render tree / image code, simply because the ultimate consequence was a crash 
> in JIT code. I won’t speak for Michael’s specific coding style preferences, 
> but I will say that in general we need to keep our code accessible even to 
> unfamiliar folks in order to accommodate work like that.

I think you are referring to  Improper copying of 
image data in ImageBufferData::getData cause crash in fastMalloc below 
JSC::FunctionBodyNode::finishParsing. That was a fun bug to track down!  This 
was a malloc overrun where the allocation site did some math with one set of 
width and height and the use site used different width and height value for 
writing to the buffer.  The root of this issue could have been prevented with 
better local variable names.  For example, there was some confusion between 
width and destw.  Looking back, several local variable name were not 
descriptive enough.  t think the code was eliminated shortly after the fix I 
did went in so it is no longer an issue.

Back to the “auto" discussion, I have been following closely and like where we 
are heading.  The use of auto should make the code easier to read.  If we have 
to rely on a tools to find the type, then we should use the type and not auto.  
Until we have a standard as to what m

[webkit-dev] JavaScript Stack Changes

[Michael Saboff]

We have been making changes to the JavaScript native stack layout in order to 
align the layout more closely with native C/C++ stack layout. This is being 
done as part of integrating LLVM as a back-end for the FTL JIT.  This is being 
tracked with the umbrella bug https://bugs.webkit.org/show_bug.cgi?id=116888.

We have already changed the stack direction from growing up in address to 
growing down.  We are in the process of changing calls from JavaScript to C 
helpers to be compliant with native calling conventions by changing calls using 
JITStubCall.h to use CCallHelpers.h (tracked with 
https://bugs.webkit.org/show_bug.cgi?id=122287).  Other tasks that remain are 
to rearrange the layout of JSStack so that the CallerFrame and ReturnPC frame 
location are consistent with native C stack conventions, using the native stack 
pointer register instead of reserving our own register, and modifying the 
thunks used to invoke JavaScript from C/C++ code.

The JavaScript team at Apple will make and test the changes to support X86 and 
X86_64 for Mac OS X and Windows, and ARM Thumb 2.  We will likely make 
speculative changes for the other ports (ARM Traditional, MIPS and SH4), but 
have no means to test those changes. If you maintain the processor specific 
JavaScript code for one of those ports, send me a reply so we can coordinate 
changes to minimize breakage.

- Michael Saboff

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] LLInt alignment problem on ARM

[Michael Saboff]

I’m wondering if the alignment is the traditional ARM vs Thumb 2.  The movw 
after lint_begin with hex  0xe30b3eef is a Thumb 2 instruction.

- Michael

On Sep 26, 2013, at 9:24 AM, Oliver Hunt  wrote:

> I believe that there’s a mnemonic that forces alignment that we could 
> (arguably should?) be using before these labels.
> 
> IIRC it’s something like .align N — if we aren’t doing this already we could 
> make the lint assembler backend emit a .align 16 prior to each global symbol.
> 
> —Oliver
> 
> On Sep 26, 2013, at 1:09 AM, Gabor Rapcsanyi  wrote:
> 
>> Hello!
>> 
>> I'm fighting with a strange LLInt alignment problem on ARM. As I see we put 
>> the LLInt code into .rodata section instead of .text.
>> Is there a specific reason why we are doing this? If there is not I would 
>> put them to the .text section.
>> 
>> Here is the objdump:
>> 
>> ./Source/JavaScriptCore/.obj/release-shared/llint/LowLevelInterpreter.o: 
>> file format elf32-littlearm
>> 
>> Disassembly of section .rodata:
>> 
>>  <_ZStL19piecewise_construct>:
>>  0:   andeq   r0, r0, r0
>> 
>> 0004 <_ZStL13allocator_arg>:
>>  4:   andeq   r0, r0, r0
>> 
>> 0008 <_ZStL6ignore>:
>>   ...
>> 
>> 0009 :
>>  9:   e30b3eefmovwr3, #48879  ; 0xbeef
>>  d:   e34b3badmovtr3, #48045  ; 0xbbad
>> 11:   e583str r0, [r3]
>> 15:   e3a0mov r0, #0
>> 19:   e12fff30blx r0
>> 
>> 001d :
>> 1d:   e1a0200emov r2, lr
>> 21:   e5852010str r2, [r5, #16]
>> 25:   e5951008ldr r1, [r5, #8]
>> ...
>> 
>> 
>> The problem is that these traditional instructions are lying on odd adresses 
>> in the .rodata section.
>> 
>> Regards,
>> Gabor
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Instrumenting the LLint interpreter

[Michael Saboff]

The LLint is used to execute Javascript the first time a function is run.  If 
code is executed multiple times, the baseline JIT will come into play.  For 
Javascript that executes once or very few times, only the LLint is used.

- Michael

On Jul 11, 2013, at 12:51 AM, Abhishek Bichhawat 
 wrote:

> Thanks Filip.
> Is it the case that the LLInt would be used in applications? Or it is just 
> going to be confined to the JIT opcodes?
> 
> Thanks and Regards,
> Abhishek
> 
> From: Filip Pizlo 
> To: Abhishek Bichhawat  
> Cc: "webkit-dev@lists.webkit.org"  
> Sent: Wednesday, 10 July 2013 4:31 PM
> Subject: Re: [webkit-dev] Instrumenting the LLint interpreter
> 
> It is possible to edit the LLInt and make it behave differently. 
> 
> -Filip
> 
> On Jul 10, 2013, at 2:22 AM, Abhishek Bichhawat 
>  wrote:
> 
>> Hi,
>> 
>> With the classical interpreter being put off, is it possible to instrument 
>> the llint interpreter to make the opcodes work in a different way or behave 
>> differently. 
>> Alternatively, is there any other method to instrument our own 
>> functionalities in the bytecode generated.
>> 
>> Thanks and Regards,
>> Abhishek
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Should we create an 8-bit path from the network stack to the parser?

[Michael Saboff]

No complaints with the long term direction.  I agree that it is a tall order to 
implement.

- Michael

On Mar 11, 2013, at 9:54 AM, Adam Barth  wrote:

> Oh, Ok.  I misunderstood your original message to say that the project
> as a whole had reached this conclusion, which certainly isn't the
> case, rather than that you personally had reached that conclusion.
> 
> As for the long-term direction of the HTML parser, my guess is that
> the optimum design will be to deliver the network bytes to the parser
> directly on the parser thread.  On the parser thread, we can merge
> charset decoding, input stream pre-processing, and tokenization to
> move directly from network bytes to CompactHTMLTokens.  That approach
> removes a number of copies, 8-bit-to-16-bit, and 16-bit-to-8-bit
> conversions.  Parsing directly into CompactHTMLTokens also means we
> won't have to do any copies or conversions at all for well-known
> strings (e.g., "div" and friends from HTMLNames).
> 
> If you're about to reply complaining about the above, please save your
> complaints for another time.  I realize that some parts of that design
> will be difficult or impossible to implement on some ports due to
> limitations on how then interact with their networking stack.  In any
> case, I don't plan to implement that design anytime soon, and I'm sure
> we'll have plenty of time to discuss its merits in the future.
> 
> Adam
> 
> 
> On Mon, Mar 11, 2013 at 8:56 AM, Michael Saboff  wrote:
>> Maciej,
>> 
>> *I* deemed using a character type template for the HTMLTokenizer as being
>> unwieldy.  Given there was the existing SegmentedString input abstraction,
>> it made logical sense to put the 8/16 bit coding there.  If I would have
>> moved the 8/16 logic into the tokenizer itself, we might have needed to do
>> 8->16 up conversions when a SegmentedStrings had mixed bit-ness in the
>> contained substrings.  Even if that wasn't the case, the patch would have
>> been far larger and likely include tricky code for escapes.
>> 
>> As I got into the middle of the 8-bit strings, I realized that not only
>> could I keep performance parity, but some of the techniques I came up with
>> offered good performance improvement.  The HTMLTokenizer ended up being one
>> of those cases.  This patch required a couple of reworks for performance
>> reasons and garnered a lot of discussion from various parts of the webkit
>> community.  See https://bugs.webkit.org/show_bug.cgi?id=90321 for the trail.
>> Ryosuke noted that this patch was responsible for a 24% improvement in the
>> url-parser test in their bots (comment 47).  My performance final results
>> are in comment 43 and show between 1 and 9% progression on the various HTML
>> parser tests.
>> 
>> Adam, If you believe there is more work to be done in the HTMLTokenizer,
>> file a bug and cc me.  I'm interested in hearing your thoughts.
>> 
>> - Michael
>> 
>> On Mar 9, 2013, at 4:24 PM, Maciej Stachowiak  wrote:
>> 
>> 
>> On Mar 9, 2013, at 3:05 PM, Adam Barth  wrote:
>> 
>> 
>> In retrospect, I think what I was reacting to was msaboff statement
>> that an unnamed group of people had decided that the HTML tokenizer
>> was too unwieldy to have a dedicated 8-bit path.  In particular, it's
>> unclear to me who made that decision.  I certainly do not consider the
>> matter decided.
>> 
>> 
>> It would be good to find out who it was that said that (or more
>> specifically: "Using a character type template approach was deemed to be too
>> unwieldy for the HTML tokenizer.") so you can talk to them about it.
>> 
>> Michael?
>> 
>> Regards,
>> Maciej
>> 
>> 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Should we create an 8-bit path from the network stack to the parser?

[Michael Saboff]

Maciej,

*I* deemed using a character type template for the HTMLTokenizer as being 
unwieldy.  Given there was the existing SegmentedString input abstraction, it 
made logical sense to put the 8/16 bit coding there.  If I would have moved the 
8/16 logic into the tokenizer itself, we might have needed to do 8->16 up 
conversions when a SegmentedStrings had mixed bit-ness in the contained 
substrings.  Even if that wasn't the case, the patch would have been far larger 
and likely include tricky code for escapes.

As I got into the middle of the 8-bit strings, I realized that not only could I 
keep performance parity, but some of the techniques I came up with offered good 
performance improvement.  The HTMLTokenizer ended up being one of those cases.  
This patch required a couple of reworks for performance reasons and garnered a 
lot of discussion from various parts of the webkit community.  See 
https://bugs.webkit.org/show_bug.cgi?id=90321 for the trail.  Ryosuke noted 
that this patch was responsible for a 24% improvement in the url-parser test in 
their bots (comment 47).  My performance final results are in comment 43 and 
show between 1 and 9% progression on the various HTML parser tests.

Adam, If you believe there is more work to be done in the HTMLTokenizer, file a 
bug and cc me.  I'm interested in hearing your thoughts.

- Michael

On Mar 9, 2013, at 4:24 PM, Maciej Stachowiak  wrote:

> 
> On Mar 9, 2013, at 3:05 PM, Adam Barth  wrote:
>> 
>> In retrospect, I think what I was reacting to was msaboff statement
>> that an unnamed group of people had decided that the HTML tokenizer
>> was too unwieldy to have a dedicated 8-bit path.  In particular, it's
>> unclear to me who made that decision.  I certainly do not consider the
>> matter decided.
> 
> It would be good to find out who it was that said that (or more specifically: 
> "Using a character type template approach was deemed to be too unwieldy for 
> the HTML tokenizer.") so you can talk to them about it.
> 
> Michael?
> 
> Regards,
> Maciej
> 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Should we create an 8-bit path from the network stack to the parser?

[Michael Saboff]

The various tokenizers / lexers work various ways to handle LChar versus UChar 
input streams.  Most of the other tokenizers are templatized on input character 
type. In the case of HTML, the tokenizer handles a UChar character at a time.  
For 8 bit input streams, the zero extension of a LChar to a UChar is zero cost. 
 There may be additional performance to be gained by doing all other possible 
handling in 8 bits, but an 8 bit stream can still contain escapes that need a 
UChar representation as you point out.  Using a character type template 
approach was deemed to be too unwieldy for the HTML tokenizer.  The HTML 
tokenizer uses SegmentedString's that can consist of sub strings with either 
LChar and UChar.  That is where the LChar to UChar zero extension happens for 
an 8 bit sub string.

My research showed that at the time showed that there were very few UTF-16 only 
resources (<<5% IIRC), although I expect the number to grow.

- Michael


On Mar 7, 2013, at 11:11 AM, Adam Barth  wrote:

> The HTMLTokenizer still works in UChars.  There's likely some
> performance to be gained by moving it to an 8-bit character type.
> There's some trickiness involved because HTML entities can expand to
> characters outside of Latin-1. Also, it's unclear if we want two
> tokenizers (one that's 8 bits wide and another that's 16 bits wide) or
> if we should find a way for the 8-bit tokenizer to handle, for
> example, UTF-16 encoded network responses.
> 
> Adam
> 
> 
> On Thu, Mar 7, 2013 at 10:11 AM, Darin Adler  wrote:
>> No. I retract my question. Sounds like we already have it right! thanks for 
>> setting me straight.
>> 
>> Maybe some day we could make a non copying code path that points directly at 
>> the data in the SharedBuffer, but I have no idea if that'd be beneficial.
>> 
>> -- Darin
>> 
>> Sent from my iPhone
>> 
>> On Mar 7, 2013, at 10:01 AM, Michael Saboff  wrote:
>> 
>>> There is an all-ASCII case in TextCodecUTF8::decode().  It should be 
>>> keeping all ASCII data as 8 bit.  TextCodecWindowsLatin1::decode() has not 
>>> only an all-ASCII case, but it only up converts to 16 bit in a couple of 
>>> rare cases.  Is there some other case you don't think we are handling?
>>> 
>>> - Michael
>>> 
>>> On Mar 7, 2013, at 9:29 AM, Darin Adler  wrote:
>>> 
>>>> Hi folks.
>>>> 
>>>> Today, bytes that come in from the network get turned into UTF-16 by the 
>>>> decoding process. We then turn some of them back into Latin-1 during the 
>>>> parsing process. Should we make changes so there’s an 8-bit path? It might 
>>>> be as simple as writing code that has more of an all-ASCII special case in 
>>>> TextCodecUTF8 and something similar in TextCodecWindowsLatin1.
>>>> 
>>>> Is there something significant to be gained here? I’ve been wondering this 
>>>> for a while, so I thought I’d ask the rest of the WebKit contributors.
>>>> 
>>>> -- Darin
>>>> ___
>>>> webkit-dev mailing list
>>>> webkit-dev@lists.webkit.org
>>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Should we create an 8-bit path from the network stack to the parser?

[Michael Saboff]

There is an all-ASCII case in TextCodecUTF8::decode().  It should be keeping 
all ASCII data as 8 bit.  TextCodecWindowsLatin1::decode() has not only an 
all-ASCII case, but it only up converts to 16 bit in a couple of rare cases.  
Is there some other case you don't think we are handling?

- Michael

On Mar 7, 2013, at 9:29 AM, Darin Adler  wrote:

> Hi folks.
> 
> Today, bytes that come in from the network get turned into UTF-16 by the 
> decoding process. We then turn some of them back into Latin-1 during the 
> parsing process. Should we make changes so there’s an 8-bit path? It might be 
> as simple as writing code that has more of an all-ASCII special case in 
> TextCodecUTF8 and something similar in TextCodecWindowsLatin1.
> 
> Is there something significant to be gained here? I’ve been wondering this 
> for a while, so I thought I’d ask the rest of the WebKit contributors.
> 
> -- Darin
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] YARR example

[Michael Saboff]

Ognian,

For the search to be case insensitive, you add an 'i' to the end of the regular 
expression.  The replace will be whatever string to have for the second 
argument.  See http://www.w3schools.com/jsref/jsref_replace.asp for an example 
of case-insensitive search/replace.

- Michael

On Jan 4, 2013, at 1:57 AM, Ognian Milanov  wrote:

> Thanks for your reply!
> 
> I already figured out how to make a case sensitive replacement with 
> String::replace, which works exactly as I wanted. However case-insensitive 
> replacement with (?i) doesn't work at all. Is this implementation specific, 
> do I need to use other notation to indicate case insensitive matching?
> 
> Regards,
> Ognian
> 
> On Thu, Jan 3, 2013 at 6:28 PM, Michael Saboff  wrote:
> Ognian,
> 
> YARR is the regular expression engine for the JavaScriptCore part of webkit.  
> It can find the matches, but you would need to write other C++ code to do the 
> replacement.  The String.replace() method will do what you want in JavaScript.
> 
> - Michael
> 
> 
> On Jan 3, 2013, at 4:16 AM, Ognian Milanov  wrote:
> 
> > Hello! I need info how to use YARR to replace all matches of a given 
> > regular expression in a string with another string. For example in Java 
> > this is achieved by String.replaceAll method.
> >
> > I will appreciate if someone leads me to the solution, thanks!
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] YARR example

[Michael Saboff]

Ognian,

YARR is the regular expression engine for the JavaScriptCore part of webkit.  
It can find the matches, but you would need to write other C++ code to do the 
replacement.  The String.replace() method will do what you want in JavaScript.

- Michael


On Jan 3, 2013, at 4:16 AM, Ognian Milanov  wrote:

> Hello! I need info how to use YARR to replace all matches of a given regular 
> expression in a string with another string. For example in Java this is 
> achieved by String.replaceAll method.
> 
> I will appreciate if someone leads me to the solution, thanks!
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] question about jsc

[Michael Saboff]

The output of "undefined" is normal.  It is the result of the expression you 
entered.  jsc is basically returning the result of the expressions you enter.  
Both var and print themselves evaluate to "undefined".  If you try "x = 1;" 
you'll get 1 as that expression returns 1.  

Concerning testing,  If you have successfully built testapi, from the webkit 
top directory you can run Tools/Scripts/run-javascriptcore-tests.  This script 
will first run testapi, which tests the JavaScript APIs and then run a 
collection of javascript tests.  If you have successfully built testRegExp, you 
can run run-regexp-tests which will test the regular expression engine.  Both 
testapi and testRegExp should be built along with jsc when you run the script 
Tools/Scripts/build-jsc.

- Michael

On Oct 29, 2012, at 2:39 AM, yuqing cai  wrote:

> hi, all, I try to port the webkit to a new platform(the platform is
> linux based run with glibc & glib, but not gtk), now I have build the
> jsc project successfully, but when I run the jsc program, something
> happend show as below:
> 
> qing@HAHA:/data/project/webOS/WebKit/Source/JavaScriptCore/JavaScriptCore.catwalk$
> ./jsc
>> var string="hello world :)";
> undefined
>> print(string);
> hello world :)
> undefined
>> 
> 
> now I have 2 questions:
> 1. Why the word "undefined" comes up?
> 2. How to test the jsc program?
> 
> qing
> 2012-10-29
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] 8 Bit String Handling in Render Text Code

[Michael Saboff]

Got a patch for review to change the macro to ENABLE_8BIT_TEXTRUN.  
(https://bugs.webkit.org/attachment.cgi?id=168988&action=review)

- Michael

On Oct 15, 2012, at 2:44 PM, Maciej Stachowiak  wrote:

> 
> On Oct 15, 2012, at 9:56 AM, Michael Saboff  wrote:
> 
>> I recently landed r131311 which adds code to handle 8-bit strings in the 
>> render text path.  The code also puts HTML text into 8-bit strings.
>> 
>> The reason for this announcement is that the handling of 8-bit text on the 
>> render path is disabled on non-Mac platforms.  Most platforms have platform 
>> specific text rendering code and that code needs to be updated to handle 
>> 8-bit text.  For Mac, the platform specific changes are for the complex text 
>> rendering path only.  The changes involved converting the 8-bit text to a 
>> 16-bit String, adding the 16-bit string to the ComplexTextController so the 
>> string won't be freed and using the contained 16-bit text with the rest of 
>> the complex code unchanged.  See 
>> ComplexTextController::collectComplexTextRuns() in 
>> WebCore/platform/graphics/mac/ComplexTextController.cpp.
>> 
>> The new define WTF_USE_8BIT_TEXTRUN is used to control the creation of 8-bit 
>> TextRun objects.  When this define is not enabled, TextRun's will only 
>> contain 16-bit text and current code should work correctly.  After platform 
>> code is added to handle 8-bit text in platform specific code, that platform 
>> should enable WTF_USE_8BIT_TEXTRUN.  Note that all platforms compile with 
>> that define enabled, but it is likely they'll crash when running the tests.
> 
> Minor technicality, but this should be an ENABLE flag, not USE. ENABLE is for 
> optional code in WebKit itself, USE is for optional external dependencies.
> 
> Regards,
> Maciej
> 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] 8 Bit String Handling in Render Text Code

[Michael Saboff]

I recently landed r131311 which adds code to handle 8-bit strings in the render 
text path.  The code also puts HTML text into 8-bit strings.

The reason for this announcement is that the handling of 8-bit text on the 
render path is disabled on non-Mac platforms.  Most platforms have platform 
specific text rendering code and that code needs to be updated to handle 8-bit 
text.  For Mac, the platform specific changes are for the complex text 
rendering path only.  The changes involved converting the 8-bit text to a 
16-bit String, adding the 16-bit string to the ComplexTextController so the 
string won't be freed and using the contained 16-bit text with the rest of the 
complex code unchanged.  See ComplexTextController::collectComplexTextRuns() in 
WebCore/platform/graphics/mac/ComplexTextController.cpp.

The new define WTF_USE_8BIT_TEXTRUN is used to control the creation of 8-bit 
TextRun objects.  When this define is not enabled, TextRun's will only contain 
16-bit text and current code should work correctly.  After platform code is 
added to handle 8-bit text in platform specific code, that platform should 
enable WTF_USE_8BIT_TEXTRUN.  Note that all platforms compile with that define 
enabled, but it is likely they'll crash when running the tests.

- Michael

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] A proposal for handling "failing" layout tests and TestExpectations

[Michael Saboff]

It seems to me that there are two issues here.  One is Chromium specific about 
process conformity.  It seems to me that should stay a Chromium issue without 
making the mechanism more complex for all ports.  The other ports seem to make 
things work using the existing framework.

The other broader issue is failing tests.  If I understand part of Filip's 
concern it is a signal to noise issue.  We do not want the pass / fail signal 
to be lost in the noise of expected failures.  Failing tests should be fixed as 
appropriate for failing platform(s).  That fixing might involve splitting off 
or removing a failing sub-test so that the remaining test adds value once 
again.  Especially "a pass becoming a fail" edge.  For me, a test failing 
differently provides unknown value as the noise of it being a failing test 
likely exceeds the benefit of the different failure mode signal.  It takes a 
non-zero effort to filter that noise and that effort is likely better spent 
fixing the test.

- Michael

On Aug 15, 2012, at 12:48 PM, Dirk Pranke  wrote:

> I've received at least one bit of feedback off-list that it might not
> have been clear what problems I was trying to solve and whether the
> solution would add enough benefit to be worth it. Let me try to
> restate things, in case this helps ...
> 
> The problems I'm attempting to solve are:
> 
> 1) Chromium does things differently from the other WebKit ports, and
> this seems bad :).
> 
> 2) the TestExpectations syntax is too complicated
> 
> 3) When you suppress or skip failures (as chromium does), you can't
> easily tell when test changes behavior (starts failing differently).
> 
> 4) We can't easily tell if a test's -expected output is actually
> believed to be correct or not, which makes figuring out whether to
> rebaseline or not difficult, and makes figuring out if your change
> that is causing a test to "fail" is actually introducing a new
> problem, just failing differently, or even potentially fixing
> something.
> 
> I agree that it's unclear how much churn there will be and how much
> benefit there will be, but we've been talking about these problems for
> years and I think without actually trying *something* we won't know if
> there's a better way to solve this or not, and I personally think it's
> worth trying. The solution I've described is the least intrusive
> mechanism we can try that I've yet come up with.
> 
> -- Dirk
> 
> On Wed, Aug 15, 2012 at 12:22 PM, Dirk Pranke  wrote:
>> Hi all,
>> 
>> As many of you know, we normally treat the -expected files as
>> "regression" tests rather than "correctness" tests; they are intended
>> to capture the current behavior of the tree. As such, they
>> historically have not distinguished between a "correct failure" and an
>> "incorrect failure".
>> 
>> The chromium port, however, has historically often not checked in
>> expectations for tests that are currently failing (or even have been
>> failing for a long time), and instead listed them in the expectations
>> file. This was primarily motivated by us wanting to know easily all of
>> the tests that were "failing". However, this approach has its own
>> downsides.
>> 
>> I would like to move the project to a point where all of the ports
>> were basically using the same workflow/model, and combine the best
>> features of each approach [1].
>> 
>> To that end, I propose that we allow tests to have expectations that
>> end in '-passing' and '-failing' as well as '-expected'.
>> 
>> The meanings for '-passing' and '-failing' should be obvious, and
>> '-expected' can continue the current meaning of either or both of
>> "what we expect to happen" and "I don't know if this is correct or
>> not" :).
>> 
>> A given test will be allowed to only have one of the three potential
>> results at any one time/revision in a checkout. [2]
>> 
>> Because '-expected' will still be supported, this means that ports can
>> continue to work as they do today and we can try -passing/-failing on
>> a piecemeal basis to see if it's useful or not.
>> 
>> Ideally we will have some way (via a presubmit hook, or lint checks,
>> or something) to be able to generate a (checked-in) list (or perhaps
>> just a dashboard or web page) of all of the currently failing tests
>> and corresponding bugs from the "-failing" expectations, so that we
>> can keep one of the advantages that chromium has gotten out of their
>> TestExpectations files [3].
>> 
>> I will update all of the tools (run-webkit-tests, garden-o-matic,
>> flakiness dashboard, etc.) as needed to make managing these things as
>> easy as possible. [4]
>> 
>> Thoughts? I'm definitely open to suggestions/variants/other ideas/etc.
>> 
>> -- Dirk
>> 
>> Notes:
>> 
>> [1] Both the "check in the failures" and the "suppress the failures"
>> approaches have advantages and disadvantages:
>> 
>> Both approaches have their advantages and disadvantages:
>> 
>> Advantages for checking in failures:
>> 
>> * you can tell when a test starts failing differe

Re: [webkit-dev] 8 Bit Strings Turned On in JavaScriptCore

[Michael Saboff]

On Nov 18, 2011, at 11:18 AM, Adam Roben wrote:

> On Nov 18, 2011, at 2:14 PM, Michael Saboff wrote:
> 
>> Although the UChar* characters() method for the various string classes still 
>> works, all new code should check what "flavor" a string is constructed by 
>> using the new is8Bit() method on the various string classes.  After 
>> determining the flavor, a call to either LChar* characters8() or UChar* 
>> characters16() as appropriate should be done to access the raw characters of 
>> a string.  The call to characters() on an 8 bit string will create a 16 bit 
>> buffer and convert the native 8 bit string, keeping the conversion for 
>> future use, before returning the 16bit result.  Obviously the expense of 
>> this conversion grows with a string's length and it increases the memory 
>> footprint beyond what was required by the original 16 bit string 
>> implementation.
> 
> I wonder what we could do to make it more obvious what the correct usage is. 
> For example, we could rename characters() to make it clear that it might 
> allocate a new buffer. And we could make it an error to call characters8() or 
> characters16() on the wrong kind of string.

We have talked about renaming and ultimately eliminating characters(), At this 
point, it may make sense to keep it but drastically reduce its use (error 
messages and the like).  I think a little more progress will help sort this out.

Concerning characters8() and characters16(), they have appropriate ASSERTS() if 
they are called incorrectly.

> -Adam
> 

- Michael

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] 8 Bit Strings Turned On in JavaScriptCore

[Michael Saboff]

With the recently landed changes in <http://trac.webkit.org/changeset/100510> 
(and two subsequent fixes in <http://trac.webkit.org/changeset/100523> and 
<http://trac.webkit.org/changeset/100729>), strings in JavaScriptCore are 
stored internally in either 8 bit or 16 bit forms.  This is implemented in the 
StringImpl class and the classes based upon it like JSC::UString and 
WTF::String. Since most platforms have a signed "char" type while a few have an 
unsigned char type or char signedness is selectable via a compiler option, we 
added typedef unsigned char LChar in .

Changes to Using Strings

Although the UChar* characters() method for the various string classes still 
works, all new code should check what "flavor" a string is constructed by using 
the new is8Bit() method on the various string classes.  After determining the 
flavor, a call to either LChar* characters8() or UChar* characters16() as 
appropriate should be done to access the raw characters of a string.  The call 
to characters() on an 8 bit string will create a 16 bit buffer and convert the 
native 8 bit string, keeping the conversion for future use, before returning 
the 16bit result.  Obviously the expense of this conversion grows with a 
string's length and it increases the memory footprint beyond what was required 
by the original 16 bit string implementation.

The various string construction methods as well as Identifier constructors have 
been modified to create natively sized strings.  The JavaScriptCore lexers and 
parsers favor making 8 bit strings where possibly, even if the source text is 
16 bit.  There are cases where parsing an 8 bit native source string will 
produce a 16 bit string, e.g. the string literal "abc\u1234".

Future Work

This change and it's prior dependent changes are not the end of the 8 bit 
string work.  In fact it should be seen as the foundation for the real 8 bit 
string work tuning JavaScriptCore and also in WebCore. The goal is to make 
WebCore's processing of text use appropriately sized strings. For Latin-1 based 
documents, string processing will be done using 8 bits except where string 
escapes require 16 bit strings. 

- Michael Saboff
msab...@apple.com

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev