Re: [webkit-dev] PSA: Distinguishing between failed release assertions and other crashes

[Mark Lam]

FYI, the change has landed in r196397: .

> On Feb 10, 2016, at 3:01 PM, Mark Lam  wrote:
> 
> As I shared in a previous email, I’ll be changing the implementation of 
> WTFCrash() for non-debug OS(DARWIN) builds to use an inlined asm statement 
> that issues a breakpoint instruction.  See 
> https://bugs.webkit.org/show_bug.cgi?id=153996 for details and discussion.  I 
> will be landing this patch shortly.
> 
> After this patch lands, for release builds, failed assertions will manifest 
> as a EXC_BREAKPOINT (SIGTRAP).  Failed assertions should be your only source 
> of EXC_BREAKPOINT crashes.
> For debug builds, failed assertions will continue to manifest as 
> EXC_BAD_ACCESS (SIGSEGV) on access of invalid address 0xbbadbeef.
> 
> Again, this change will only apply to OS(DARWIN) builds.  I’m leaving it up 
> to the linux folks to decide if they also want to adopt this behavior on 
> linux.
> 
> 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] PSA: Distinguishing between failed release assertions and other crashes

[Mark Lam]

As I shared in a previous email, I’ll be changing the implementation of 
WTFCrash() for non-debug OS(DARWIN) builds to use an inlined asm statement that 
issues a breakpoint instruction.  See 
https://bugs.webkit.org/show_bug.cgi?id=153996 for details and discussion.  I 
will be landing this patch shortly.

After this patch lands, for release builds, failed assertions will manifest as 
a EXC_BREAKPOINT (SIGTRAP).  Failed assertions should be your only source of 
EXC_BREAKPOINT crashes.
For debug builds, failed assertions will continue to manifest as EXC_BAD_ACCESS 
(SIGSEGV) on access of invalid address 0xbbadbeef.

Again, this change will only apply to OS(DARWIN) builds.  I’m leaving it up to 
the linux folks to decide if they also want to adopt this behavior on linux.

Thanks.

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

Re: [webkit-dev] [cmake] Proposal: Move commonly used platform-dependent files in WebCore to .cmake include files.

[Konstantin Tokarev]

09.02.2016, 22:19, "Alex Christensen" :
>  Let’s go for it. Less duplication is a good thing. The only downside is the 
> occasional “Which CMake file do I add this to?” but that should be just as 
> straightforward as adding the file to multiple platform cmake files, if not 
> more.

That's a really good point.

I've moved new cmake file to WebCore root which is less cluttered with files 
than WebCore/platform, and gave it more remarkable capitalization (*).

I've tried another (and probably more cmake'ish) approach is to use 
add_subdirectory() with CMakeLists.txt on lower levels, but hit an issue with 
CMake variable scoping: it is not trivial to ensure that CMakeLists.txt on all 
levels can modify the same WebCore_* variables.

First patch is here:
https://bugs.webkit.org/show_bug.cgi?id=154074

---
(*) My original idea was to put include files close to their source dirs and 
align with dir names, but that certainly does not work for multi-direcotry 
things like gstreamer.


>>   On Feb 9, 2016, at 10:44 AM, Michael Catanzaro  
>> wrote:
>>
>>   I'm curious what Martin and Alex think about this. It seems fine to me;
>>   the downside is there are more CMake files to maintain, the upside is
>>   the big ones should be slightly smaller, and we can reduce duplication
>>   between PlatformEFL.cmake and PlatformGTK.cmake.
>>
>>   Michael
>>   ___
>>   webkit-dev mailing list
>>   webkit-dev@lists.webkit.org
>>   https://lists.webkit.org/mailman/listinfo/webkit-dev


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

Re: [webkit-dev] Thought about Nix JavaScriptCore port

[Filip Pizło]

> On Feb 10, 2016, at 9:14 AM, Konstantin Tokarev  wrote:
> 
> 
> 
> 10.02.2016, 20:10, "Filip Pizło" :
>>>  On Feb 10, 2016, at 1:40 AM, Konstantin Tokarev  wrote:
>>> 
>>>  10.02.2016, 05:41, "Eric Wing" :
>  On 2/7/16, Konstantin Tokarev  wrote:
>   Please try updated version of my branch, it now does not use LLVM 
> unless you
>   enable USE_LLVM_DISASSEMBLER.
 
  I merged your branch. That seemed to build and work.
  So what would USE_LLVM_DISAAEMBLER get me if I could build it?
>>> 
>>>  It will allow you to disassemble JIT code on architectures that are 
>>> supported by LLVM but lack specialized disassembler inside JSC, e.g. it was 
>>> known to work on ARM traditional.
>> 
>> We should drop the llvm disassembler support since we don't need it for 
>> ARM64, ARMv7, or x86. If we care about disassembly on ARM traditional, we 
>> should write one. It's not that hard.
> 
> Out of curiosity, what is the reason not to reuse LLVM disassemblers? Just 
> because LLVM is "inconvenient" dependency?

It's extremely inconvenient since it doesn't have a stable API. Also in our 
experience that disassembler sometimes only supports those instructions that 
llvm would emit. If you look you'll see that on x86 we choose between the llvm 
disassembler and our own based on whether llvm generated the code or we did, 
since the llvm disassembler has historically had issues handling some of the 
instructions that out MacroAssembler know about. 

There's nothing worse than debugging a jit bug and being blocked on an upstream 
disassembler lacking a feature. It's much better if we have our own. That way 
we won't be blocked. 

> 
> -- 
> Regards,
> Konstantin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Thought about Nix JavaScriptCore port

[Konstantin Tokarev]

10.02.2016, 20:10, "Filip Pizło" :
>>  On Feb 10, 2016, at 1:40 AM, Konstantin Tokarev  wrote:
>>
>>  10.02.2016, 05:41, "Eric Wing" :
  On 2/7/16, Konstantin Tokarev  wrote:
   Please try updated version of my branch, it now does not use LLVM unless 
 you
   enable USE_LLVM_DISASSEMBLER.
>>>
>>>  I merged your branch. That seemed to build and work.
>>>  So what would USE_LLVM_DISAAEMBLER get me if I could build it?
>>
>>  It will allow you to disassemble JIT code on architectures that are 
>> supported by LLVM but lack specialized disassembler inside JSC, e.g. it was 
>> known to work on ARM traditional.
>
> We should drop the llvm disassembler support since we don't need it for 
> ARM64, ARMv7, or x86. If we care about disassembly on ARM traditional, we 
> should write one. It's not that hard.

Out of curiosity, what is the reason not to reuse LLVM disassemblers? Just 
because LLVM is "inconvenient" dependency?

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

Re: [webkit-dev] Thought about Nix JavaScriptCore port

[Filip Pizło]

> On Feb 10, 2016, at 1:40 AM, Konstantin Tokarev  wrote:
> 
> 
> 
> 10.02.2016, 05:41, "Eric Wing" :
>>> On 2/7/16, Konstantin Tokarev  wrote:
>>>  Please try updated version of my branch, it now does not use LLVM unless 
>>> you
>>>  enable USE_LLVM_DISASSEMBLER.
>> 
>> I merged your branch. That seemed to build and work.
>> So what would USE_LLVM_DISAAEMBLER get me if I could build it?
> 
> It will allow you to disassemble JIT code on architectures that are supported 
> by LLVM but lack specialized disassembler inside JSC, e.g. it was known to 
> work on ARM traditional.

We should drop the llvm disassembler support since we don't need it for ARM64, 
ARMv7, or x86. If we care about disassembly on ARM traditional, we should write 
one. It's not that hard. 

> 
>> Also, are there things I can do to shrink JavaScriptCore?

Disable various optimizing JITs if you're desperate enough. 

But I think you could also reduce size by experimenting with out-of-lining cold 
functions that are currently online. That would be a longer term project. 

> 
> 
> You can try to disable all code related to disassembler and inspector (if you 
> don't need these features).
> 
> Also you can try building without API/JSCTestRunnerUtils.cpp and 
> runtime/TestRunnerUtils.cpp.
> 
> 
>> It's now
>> over 20MB. I know ICU is a big part of that, but JSC itself seems to
>> keep getting bigger too.
>> 
>> To respond to a prior suggestion about ICU size, I am familiar with
>> the data archive option. However, there are several challenges with
>> that:
>> - I don't know what parts JSC actually needs to know what I can safely remove
> 
> 
> I second this request, it would be great if WebKit had a documentation which 
> kinds of ICU data are used by JSC and by WebCore.
> 
> 
>> - I don't know how ICU/JSC load the data archive. Android APK file
>> semantics are pretty terrible and you have to send around a Java
>> AsssetManager to access everything. Standard file library calls don't
>> 'just work'.
>> - I really need to build as a static library because since it is a
>> private implementation detail of JSC. There are problems if somebody
>> downstream of me wants to use ICU, with a potentially different
>> version. If I dynamically link and use data archives, I open up a lot
>> of conflict issues. Similarly, Android itself may use ICU internally
>> and I've been warned of conflict problems by others. Static linking
>> avoids these headaches. Also, I haven't figured out if data archive
>> and static libraries are compatible.
> 
> 
> IIRC, Android is shipped with ICU4J, and in recent ICU versions they are 
> using the same data format.
> 
> 
>> - I did notice Apple has a modified, stripped down version of ICU as
>> part of Darwin. I was unable to figure out how to get it built. It was
>> a pretty complicated Makefile.
>> 
>> Thanks,
>> Eric
>> 
>> P.S.
>> Here is an indentation fix for my previous ICU patch.
>> https://github.com/ewmailing/webkit/commit/e2c94e8b126143402b4e17cc514c4df412de5ace
> 
> -- 
> Regards,
> Konstantin
> ___
> 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] Thought about Nix JavaScriptCore port

[Darin Adler]

> On Feb 10, 2016, at 1:40 AM, Konstantin Tokarev  wrote:
> 
> 10.02.2016, 05:41, "Eric Wing" :
>> - I don't know what parts JSC actually needs to know what I can safely remove
> 
> I second this request, it would be great if WebKit had a documentation which 
> kinds of ICU data are used by JSC and by WebCore.

That’s going to change over time. We have frequently changed which functions 
and sections of ICU we use as we develop WebKit. That being said, there is no 
harm in someone carefully researching exactly what parts of ICU WebKit uses at 
a particular point in time.

Maybe since the two of you both want it, one of you would like to volunteer to 
do that?

I’m not sure there’s anyone else planning on it.

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

Re: [webkit-dev] Thought about Nix JavaScriptCore port

[Konstantin Tokarev]

10.02.2016, 05:41, "Eric Wing" :
> On 2/7/16, Konstantin Tokarev  wrote:
>>  Please try updated version of my branch, it now does not use LLVM unless you
>>  enable USE_LLVM_DISASSEMBLER.
>
> I merged your branch. That seemed to build and work.
> So what would USE_LLVM_DISAAEMBLER get me if I could build it?
> Also, are there things I can do to shrink JavaScriptCore? It's now
> over 20MB. I know ICU is a big part of that, but JSC itself seems to
> keep getting bigger too.
>
> To respond to a prior suggestion about ICU size, I am familiar with
> the data archive option. However, there are several challenges with
> that:
> - I don't know what parts JSC actually needs to know what I can safely remove
> - I don't know how ICU/JSC load the data archive. Android APK file
> semantics are pretty terrible and you have to send around a Java
> AsssetManager to access everything. Standard file library calls don't
> 'just work'.
> - I really need to build as a static library because since it is a
> private implementation detail of JSC. There are problems if somebody
> downstream of me wants to use ICU, with a potentially different
> version. If I dynamically link and use data archives, I open up a lot
> of conflict issues. Similarly, Android itself may use ICU internally
> and I've been warned of conflict problems by others. Static linking
> avoids these headaches. Also, I haven't figured out if data archive
> and static libraries are compatible.
> - I did notice Apple has a modified, stripped down version of ICU as
> part of Darwin. I was unable to figure out how to get it built. It was
> a pretty complicated Makefile.
>
> Thanks,
> Eric
>
> P.S.
> Here is an indentation fix for my previous ICU patch.
> https://github.com/ewmailing/webkit/commit/e2c94e8b126143402b4e17cc514c4df412de5ace

I stronly suggest you to submit patches into bugzilla.

If you never did it before, you can follow steps described here:
https://github.com/annulen/webkit/wiki/How-to-submit-patches-to-webkit.org

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

Re: [webkit-dev] Thought about Nix JavaScriptCore port

[Konstantin Tokarev]

10.02.2016, 05:41, "Eric Wing" :
> On 2/7/16, Konstantin Tokarev  wrote:
>>  Please try updated version of my branch, it now does not use LLVM unless you
>>  enable USE_LLVM_DISASSEMBLER.
>
> I merged your branch. That seemed to build and work.
> So what would USE_LLVM_DISAAEMBLER get me if I could build it?

It will allow you to disassemble JIT code on architectures that are supported 
by LLVM but lack specialized disassembler inside JSC, e.g. it was known to work 
on ARM traditional.

> Also, are there things I can do to shrink JavaScriptCore? 


You can try to disable all code related to disassembler and inspector (if you 
don't need these features).

Also you can try building without API/JSCTestRunnerUtils.cpp and 
runtime/TestRunnerUtils.cpp.


> It's now
> over 20MB. I know ICU is a big part of that, but JSC itself seems to
> keep getting bigger too.
>
> To respond to a prior suggestion about ICU size, I am familiar with
> the data archive option. However, there are several challenges with
> that:
> - I don't know what parts JSC actually needs to know what I can safely remove


I second this request, it would be great if WebKit had a documentation which 
kinds of ICU data are used by JSC and by WebCore.


> - I don't know how ICU/JSC load the data archive. Android APK file
> semantics are pretty terrible and you have to send around a Java
> AsssetManager to access everything. Standard file library calls don't
> 'just work'.
> - I really need to build as a static library because since it is a
> private implementation detail of JSC. There are problems if somebody
> downstream of me wants to use ICU, with a potentially different
> version. If I dynamically link and use data archives, I open up a lot
> of conflict issues. Similarly, Android itself may use ICU internally
> and I've been warned of conflict problems by others. Static linking
> avoids these headaches. Also, I haven't figured out if data archive
> and static libraries are compatible.


IIRC, Android is shipped with ICU4J, and in recent ICU versions they are using 
the same data format.


> - I did notice Apple has a modified, stripped down version of ICU as
> part of Darwin. I was unable to figure out how to get it built. It was
> a pretty complicated Makefile.
>
> Thanks,
> Eric
>
> P.S.
> Here is an indentation fix for my previous ICU patch.
> https://github.com/ewmailing/webkit/commit/e2c94e8b126143402b4e17cc514c4df412de5ace

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