Re: [webkit-dev] Bytecode Sequence for function.apply()
Well, I ran build-webkit with the "--debug" option, and when I try to run WebKit/WebKitBuild/Debug/JavaScriptCore/jsc , I get a failed assertion: ASSERTION FAILED: !isHostFunctionNonInline() (../../../JavaScriptCore/runtime/Executable.h:349 JSC::FunctionExecutable* JSC::JSFunction::jsExecutable() const) Is there a C++ I can call directly to get a bytecode dump of a JS function? - Maxime Ariya Hidayat wrote: > >> How would I go about building jsc in debug mode? Is it possible to build >> a >> standalone jsc shell? > > See https://lists.webkit.org/pipermail/webkit-qt/2010-January/89.html > for details. > > -- View this message in context: http://old.nabble.com/Bytecode-Sequence-for-function.apply%28%29-tp28623075p28675341.html Sent from the Webkit mailing list archive at Nabble.com. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Bytecode Sequence for function.apply()
> How would I go about building jsc in debug mode? Is it possible to build a > standalone jsc shell? See https://lists.webkit.org/pipermail/webkit-qt/2010-January/89.html for details. -- Ariya Hidayat http://www.linkedin.com/in/ariyahidayat ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Bytecode Sequence for function.apply()
How would I go about building jsc in debug mode? Is it possible to build a standalone jsc shell? I'm using Qt Webkit, with the bulld-webkit and run-webkit scripts. Thank you for your help, - Maxime Oliver Hunt-2 wrote: > > If you have a debug build of jsc, you can run 'jsc -d' and that will dump > the generated bytecode > > --Oliver > > On May 20, 2010, at 8:42 AM, Nyx wrote: > >> >> I've been working on a tool to generate a trace of JavaScript executions, >> built on JavaScriptCore. I'm trying to log calls to all functions and >> their >> arguments. To do this, I've instrumented the op_call and op_call_varargs >> bytecodes in Interpreter.cpp. >> >> The problem I'm having is that if someone calls a native/host function >> through apply, I don't see the call. For example, the call: >> >> string.fromCharCode.apply(null, [65, 66, 67]); >> >> Doesn't seem to correspond to an op_call or op_call_varargs, so I'm >> wondering how this is handled in JavaScriptCore, what kind of bytecodes >> generated, and if somebody has any idea what I could do to log the >> "unseen" >> calls to native functions, short of instrumenting every native function >> in >> WebKit. >> -- >> View this message in context: >> http://old.nabble.com/Bytecode-Sequence-for-function.apply%28%29-tp28623075p28623075.html >> Sent from the Webkit mailing list archive at Nabble.com. >> >> ___ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > -- View this message in context: http://old.nabble.com/Bytecode-Sequence-for-function.apply%28%29-tp28623075p28673826.html Sent from the Webkit mailing list archive at Nabble.com. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Possible issue with TCMalloc_PageHeap on Solaris 10 (amd64) ?
Hi, On Tue, 25 May 2010, Zoltan Horvath wrote: [ Please redirect me if the question is off-topic here ] webkit-help is the appropriate channel for this. Okay - I'll send a possible patch there in this case, to build on Solaris 10. Any hint or suggestion would be appreciated :) You should comple WebKit with USE_SYSTEM_MALLOC=1 then it won't use TCMalloc. We should take look that is it possible to use TCMalloc on Solaris. Thanks for the advice ; with -D USE_SYSTEM_MALLOC=1, everything is working perfectly! ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] free functions
On May 25, 2010, at 7:54 AM, Chris Jerdonek wrote: > I sometimes come across public member functions whose implementations do not > depend on private data. > > There is a school of thought that such functions are better non-member > because it reduces the number of functions coupled to private data. On the > other hand, I've heard the argument that making such functions free creates > naming issues -- it's not clear to the caller in which header file to find > the free function. > > My question for WebKit is whether naming considerations outweigh > encapsulation considerations. And if so, is there a naming convention or > otherwise that we can use to make finding free functions easier? We do need our classes to be smaller so we can understand the structure of the code. The encapsulation benefits of having a much smaller number of members in a class are well worth some cost. But there are at least two considerations that come into play when replacing a member function with a free function: 1) Free functions still have to go in some header/source file. The usual rule for finding a function is to look for a file named based on the class. Without a class name we have to do something to make it practical to find the functions in the source tree without a lot of searching. 2) Free functions need names that are clear and unambiguous with no context other than the WebCore namespace. We try to keep member function names short, and we can do so in part because they have a class name context. The same function as a free function will almost certainly need a longer name. Each time we create a free function we have to think about what an appropriate name is; it’s a mistake to leave the same short name that was previously used for a class member. Another possible way to get encapsulation benefits with fewer of the other problems is to group functions into classes or namespaces that have no data and nothing else private. This may be helpful if the class or namespace name has a good name with a clear concept. I also think that it’s fine for free functions to have longer names than member functions. Functions like the ones in SuddenTermination.h, LinkHash.h, UUID.h, and even markup.h seem to be OK as free functions, so I think we can definitely deal with these issues and use them more. But it’s something I think we have to do carefully with sensitivity until we get a little more experience with it. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Style question: static, protected, or public members
On May 25, 2010, at 3:05 AM, TAMURA, Kent wrote: >> Generally speaking I suggest we do not use the "m_" prefix for the members >> of structs. And I suggest that classes with public data members be structs >> instead of classes. Classes that have public data members only for >> historical reasons should be changed so the data members are not public. We >> should talk some specific examples. > > As for protected data members, many classes use "m_" prefix. I found > protected members without "m_" in HTMLTableCellElement and > HTMLTableColElement. I guess they are legacy code and we should use "m_" for > protected members too. Older classes did not use the "m_" prefix consistently. Public and protected members were a little slower to get changed than others because they affected more source files. We want to use "m_" for all non-static data members, but data members should also be private. Generally speaking, protected data members should be avoided entirely. Existing protected data members should generally be replaced with private data members and we can add protected accessor functions as needed. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Possible issue with TCMalloc_PageHeap on Solaris 10 (amd64) ?
Hi, On Tuesday 25 May 2010, at 16:38, Xavier Roche wrote: > Hi folks!, > > [ Please redirect me if the question is off-topic here ] webkit-help is the appropriate channel for this. > I am trying to build webkit (qt flavour, current 4.6.1 stable release) on > Solaris, and I am facing weird SEGV issues when trying to use objects such > as QWebPage. The underlying issue seems to be related to the TCMalloc* > layer. > Might be related to threading issues, too. This does not look like a > qt-centric issue, as far as I can see ; but this might be related to a > really trivial build option not set correctly - do not hesitate to give > feedback if you have a running build on Solaris. TCMalloc is internal WTF code, not qt-centric issue. You are correct. > Does anybody is experiencing the same issue on Solaris ? I've never tried to build WebKit on Solaris, but the problem may occurs by the system. > The libraries have been built on Solaris 10, amd64 (64-bit), using the > official qt-everywhere-opensource-src-4.6.1.tar.gz package, with two minor > patches (see [1] and [2]) > ... > Any hint or suggestion would be appreciated :) You should comple WebKit with USE_SYSTEM_MALLOC=1 then it won't use TCMalloc. We should take look that is it possible to use TCMalloc on Solaris. Regards, Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] free functions
Hi, I have a question regarding WebKit's stance on free functions. I sometimes come across public member functions whose implementations do not depend on private data. There is a school of thought that such functions are better non-member because it reduces the number of functions coupled to private data. On the other hand, I've heard the argument that making such functions free creates naming issues -- it's not clear to the caller in which header file to find the free function. My question for WebKit is whether naming considerations outweigh encapsulation considerations. And if so, is there a naming convention or otherwise that we can use to make finding free functions easier? --Chris ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Possible issue with TCMalloc_PageHeap on Solaris 10 (amd64) ?
Hi folks!,
[ Please redirect me if the question is off-topic here ]
I am trying to build webkit (qt flavour, current 4.6.1 stable release) on
Solaris, and I am facing weird SEGV issues when trying to use objects such
as QWebPage. The underlying issue seems to be related to the TCMalloc*
layer.
Might be related to threading issues, too. This does not look like a
qt-centric issue, as far as I can see ; but this might be related to a
really trivial build option not set correctly - do not hesitate to give
feedback if you have a running build on Solaris.
Does anybody is experiencing the same issue on Solaris ?
The libraries have been built on Solaris 10, amd64 (64-bit), using the
official qt-everywhere-opensource-src-4.6.1.tar.gz package, with two minor
patches (see [1] and [2])
Various gcc releases have been tested for the qt/webkit build with the
same effect (3.4.3, 3.4.6, 4.1.2) ; in release and debug more (-release or
-debug)
The libraries have been built using:
./configure -shared -opensource -debug -no-separate-debug-info -webkit
-xmlpatterns -fontconfig -qt-gif -qt-libjpeg -qt-libpng -qt-libtiff
-qt-libmng -no-accessibility -no-sql-sqlite -no-phonon -no-phonon-backend
-no-audio-backend -no-multimedia -no-opengl -no-qt3support -no-declarative
-no-dbus -platform solaris-g++-64 -prefix /data/qt/qt4-install -D
ALWAYS_INLINE=inline
Note: -DALWAYS_INLINE=inline added as workaround for a build oddity (see
[3]) when using -debug
I first tested various demos, including the demo/browser one (see [4]),
and I managed to have a minimal test case:
The sample application itself is really simple:
#include
#include
int main(int argc, char **argv) {
QApplication *app = new QApplication(argc, argv,
QApplication::GuiClient);
QWebPage *fakePage = new QWebPage();
fakePage->action(QWebPage::Stop);
(void) app;
fprintf(stderr, "successfully started\n");
QApplication::instance()->exec();
}
This trivial program works fine on Linux, but produces a SEGV on Solaris
on the "QWebPage *fakePage = new QWebPage()" line:
(l...@1) signal SEGV (no mapping at the fault address) at 0xfd7ffd68a9d7
at 0xfd7ffd68a9d7
0xfd7ffd68a9d7: decl %edx
Entering debugger ...
the dbx trace shows: (sorry for the meaningless stack frame - I am trying
to get a more decent version of dbx, because the verbose library release
of libQtWebKit.so is too verbose for dbx - *sigh*)
Current function is main
16 QWebPage *fakePage = new QWebPage();
(dbx) where
[1] WTF::TCMalloc_PageHeap::GrowHeap(0xfd7ffea5a47c, 0x0,
0xfd7ffa52f, 0x0, 0x0, 0x0), at 0xfd7ffd68a9d7
[2] WTF::TCMalloc_Central_FreeList::FetchFromSpansSafe(0x0, 0x0, 0x0,
0x0, 0x0, 0x0), at 0xfd7ffd68b1b1
[3] WTF::TCMalloc_Central_FreeList::RemoveRange(0x0, 0x0, 0x0, 0x0, 0x0,
0x0), at 0xfd7ffd68b58b
[4] WTF::fastMalloc(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfd7ffd68c540
[5] WTF::initializeThreading(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at
0xfd7ffd690c0e
[6] JSC::initializeThreading(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at
0xfd7ffd53f965
[7] QWebPagePrivate::QWebPagePrivate(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at
0xfd7ffdf0abf6
[8] QWebPage::QWebPage(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at
0xfd7ffdf112c5
=>[9] main(argc = 1, argv = 0xfd7fffdfd3a8), line 16 in "test-gui.cpp"
Any hint or suggestion would be appreciated :)
[1]
--- src/3rdparty/webkit/JavaScriptCore/wtf/StringExtras.h
+++ src/3rdparty/webkit/JavaScriptCore/wtf/StringExtras.h
@@ -85,7 +85,7 @@
#endif
-#if PLATFORM(WIN_OS) || PLATFORM(LINUX)
+#if PLATFORM(WIN_OS) || PLATFORM(LINUX) || PLATFORM(SOLARIS)
inline char* strnstr(const char* buffer, const char* target, size_t
bufferLength)
{
--- src/3rdparty/javascriptcore/JavaScriptCore/wtf/StringExtras.h
+++ src/3rdparty/javascriptcore/JavaScriptCore/wtf/StringExtras.h
@@ -85,7 +85,7 @@
#endif
-#if PLATFORM(WIN_OS) || PLATFORM(LINUX)
+#if PLATFORM(WIN_OS) || PLATFORM(LINUX) || PLATFORM(SOLARIS)
inline char* strnstr(const char* buffer, const char* target, size_t
bufferLength)
{
[2] workaround for sun ld : remove the '-Wl,--gc-sections' option in
src/3rdparty/webkit/WebCore/Makefile ; also replaced configure to use
bash:
for i in $(find . -type f -name configure) ; do gsed -ie
's%^#!/bin/sh%#!/bin/bash%' "$i"; done
[3]
../JavaScriptCore/wtf/PassRefPtr.h: In static member function `static
WTF::PassRefPtr WTF::ByteArray::create(size_t)':
../JavaScriptCore/wtf/PassRefPtr.h:66: sorry, unimplemented: inlining
failed in call to 'WTF::PassRefPtr::~PassRefPtr() [with T =
WTF::ByteArray]': function body not available
../JavaScriptCore/wtf/ByteArray.cpp:35: sorry, unimplemented: called from
here
[4]
(dbx) where -l
current thread: t...@1
[1]
libQtWebKit.so.4.6.1:WTF::TCMalloc_PageHeap::GrowHeap(0xfd7fff05a47c,
0x0, 0xfd7ff9faf, 0x0, 0x0, 0x0), at 0xfd7ffdc8a9d7
[2]
libQtWebKit.so.4.6.1:WTF::TCMalloc_Central_FreeList::FetchFromSpansSafe(0x0
Re: [webkit-dev] Style question: static, protected, or public members
2010/5/25 Darin Adler On May 20, 2010, at 8:54 PM, TAMURA, Kent wrote: > What's the naming rule for non-const static members? > > Some classes give "s_" prefixes: > WebCore/page/DOMTimer.h: static double s_minTimerInterval; > WebCore/page/GeolocationPositionCache.h: static int s_instances; > > FrameView gives "s" prefix: > WebCore/page/FrameView.h: static double sCurrentPaintTimeStamp; // used for detecting decoded resource thrash in the cache > > Settings gives "g" prefix: > WebCore/page/Settings.h: static bool gShouldPaintNativeControls; > WebCore/page/Settings.h: static bool gShouldUseHighResolutionTimers; If we have to use a prefix for this, I suggest the "s_" prefix. I think "s_" is reasonable. > And what about public and protected members? The style guide has no exceptions for them, so I think they should have m_. But many classes in WebCore don't use m_ for public members. Generally speaking I suggest we do not use the "m_" prefix for the members of structs. And I suggest that classes with public data members be structs instead of classes. Classes that have public data members only for historical reasons should be changed so the data members are not public. We should talk some specific examples. ok, public data members in classes should be changed. As for protected data members, many classes use "m_" prefix. I found protected members without "m_" in HTMLTableCellElement and HTMLTableColElement. I guess they are legacy code and we should use "m_" for protected members too. -- TAMURA Kent Software Engineer, Google ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Style question: static, protected, or public members
On Tue, May 25, 2010 at 12:19 AM, Darin Adler wrote: > On May 20, 2010, at 8:54 PM, TAMURA, Kent wrote: > > > What's the naming rule for non-const static members? > > > > Some classes give "s_" prefixes: > > WebCore/page/DOMTimer.h:static double s_minTimerInterval; > > WebCore/page/GeolocationPositionCache.h:static int s_instances; > > > > FrameView gives "s" prefix: > > WebCore/page/FrameView.h:static double sCurrentPaintTimeStamp; // > used for detecting decoded resource thrash in the cache > > > > Settings gives "g" prefix: > > WebCore/page/Settings.h:static bool gShouldPaintNativeControls; > > WebCore/page/Settings.h:static bool > gShouldUseHighResolutionTimers; > > If we have to use a prefix for this, I suggest the "s_" prefix. > > > And what about public and protected members? The style guide has no > exceptions for them, so I think they should have m_. But many classes in > WebCore don't use m_ for public members. > > Generally speaking I suggest we do not use the "m_" prefix for the members > of structs. And I suggest that classes with public data members be structs > instead of classes. Classes that have public data members only for > historical reasons should be changed so the data members are not public. We > should talk some specific examples. > +1 to the proposal In case this is what we decide upon, I've created a patch to update our coding style page [1]. (I'm also happy to roll another if someone has a better suggestion.) [1] https://bugs.webkit.org/show_bug.cgi?id=39663 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
