commit be9027216ccda343e2e5dc73713a5efd6b798614
author mark.lam@apple.com <mark.lam@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc> Sat Jun 18 04:26:27 2022 +0000
committer mark.lam@apple.com <mark.lam@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc> Sat Jun 18 04:26:27 2022 +0000
tree 1dd24775308904057b8f296a3869d8e255428d84
parent b82c47817d244136f2865bc9da7d9f5ab8200485

Enhance Options::useOSLog to accept an os log type value.
https://bugs.webkit.org/show_bug.cgi?id=241719

Reviewed by Yusuke Suzuki.

This option only applies to OS(DARWIN).

For example, we can now use any of these:
    --useOSLog=default    // logs to OS_LOG_TYPE_DEFAULT
    --useOSLog=info       // logs to OS_LOG_TYPE_INFO
    --useOSLog=debug      // logs to OS_LOG_TYPE_DEBUG
    --useOSLog=error      // logs to OS_LOG_TYPE_ERROR
    --useOSLog=fault.     // logs to OS_LOG_TYPE_FAULT

We can still use --useOSLog=0 or false (which means do the normal dataLog) and
--useOSLog=1 or true (which means dataLog to OS_LOG_TYPE_ERROR).

Previously, when we specify --useOSLog=1, we will log to OS_LOG_TYPE_INFO.  This
has been a source of friction in usage because no one ever remembers that we need
to enable OS_LOG_TYPE_INFO in the log stream to see this logging.  Instead,
--useOSLog=1 will now log to OS_LOG_TYPE_ERROR, which ensures that logging will
show up in log stream.  This is fine to do because the --useOSLog=1 option
indicates that the client really wants to see the logs.  Otherwise, the client
can use one of the other os log types if they want something different.

Secondly, because --useOSLog=1 indicates that the client really wants to see the
logs, logging to OS_LOG_TYPE_ERROR ensures that the logging is flushed to the
file system instead of sitting in a memory buffer, and potentially not showing up
in the log stream.

Also made the following changes:

1. Changed Options::dumpAllOptions to use dataLog instead of printing to stderr.
   This allows its output to be diverted using Options::useOSLog as well.

2. Moved the call to WTF::setDataFile from Options::initialize to
   Options::recomputeDependentOptions.  This allows Options::useOSLog to be
   specified using the jsc shell's --useOSLog argument instead of requiring it
   to be specified using the JSC_useOSLog env var in order to work.

   To enable this, added a useOSLogOptionHasChanged flag that can be set in
   the parser of the Options::useOSLog option.  This prevents
   Options::recomputeDependentOptions from calling initializeDatafileToUseOSLog()
   repeatedly every time any option is set.

3. Added initializeDatafileToUseOSLog() which now instantiates the appropriate
   OSLogPrintStream and sets it using WTF::setDataFile.

   initializeDatafileToUseOSLog() also asserts that it is called at most once.

4. Added an assertion in WTF::setDataFile() to ensure that it is not called more
   than once.

5. #if out the calls to overrideAliasedOptionWithHeuristic() on PLATFORM(COCOA).
   They are not needed because, on PLATFORM(COCOA), we already iterate through
   every env var starting with JSC_ and call Options::setOption() on it.
   Options::setOption() will also handle aliased options.

For reference, this is an example of how we can view the logs using log stream
once --useOSLog=1 is used:

    # log stream --predicate 'category == "DataLog"'

* Source/JavaScriptCore/API/glib/JSCOptions.cpp:
* Source/JavaScriptCore/jsc.cpp:
(CommandLine::parseArguments):
* Source/JavaScriptCore/runtime/Options.cpp:
(JSC::parse):
(JSC::asDarwinOSLogType):
(JSC::initializeDatafileToUseOSLog):
(JSC::asString):
(JSC::Options::recomputeDependentOptions):
(JSC::Options::initialize):
(JSC::Options::setOptionWithoutAlias):
(JSC::Options::dumpAllOptions):
(JSC::OptionReader::Option::initValue):
(JSC::OptionReader::Option::dump const):
(JSC::OptionReader::Option::operator== const):
* Source/JavaScriptCore/runtime/Options.h:
* Source/JavaScriptCore/runtime/OptionsList.h:
* Source/WTF/wtf/DataLog.cpp:
(WTF::setDataFile):

Canonical link: https://commits.webkit.org/251661@main


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@295656 268f45cc-cd09-0410-ab3c-d52691b4dbfc