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

B2-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-8

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

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

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

> 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

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

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 >

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

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 <msab...@apple.com> wrote: > > [Bringing John Lehner from the iTunes team into the discussion] > > Last I knew, the iTunes te

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

[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.

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

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

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

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++

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

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

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

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

Re: [webkit-dev] Using OfflineAsm

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

[webkit-dev] lldb scripted command for JavaScript backtrace

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,

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

The branch has been merged back to trunk in change set r163027: http://trac.webkit.org/changeset/163027. - 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

[webkit-dev] JavaScriptCore Merge of C Stack Work

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

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

On Jan 3, 2014, at 11:28 AM, Geoffrey Garen gga...@apple.com 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

[webkit-dev] JavaScript Stack Changes

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

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

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 oli...@apple.com wrote: I believe that there’s a mnemonic that forces alignment that we could

Re: [webkit-dev] Instrumenting the LLint interpreter

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

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

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

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

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 msab...@apple.com wrote: Maciej, *I

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

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? -

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

be beneficial. -- Darin Sent from my iPhone On Mar 7, 2013, at 10:01 AM, Michael Saboff msab...@apple.com 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

Re: [webkit-dev] YARR example

. 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 msab...@apple.com wrote: Ognian, YARR is the regular expression engine for the JavaScriptCore part of webkit. It can find the matches

Re: [webkit-dev] YARR example

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

Re: [webkit-dev] question about jsc

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

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

Got a patch for review to change the macro to ENABLE_8BIT_TEXTRUN. (https://bugs.webkit.org/attachment.cgi?id=168988action=review) - Michael On Oct 15, 2012, at 2:44 PM, Maciej Stachowiak m...@apple.com wrote: On Oct 15, 2012, at 9:56 AM, Michael Saboff msab...@apple.com wrote: I

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

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

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

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

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

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

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

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