Re: [Lldb-commits] [PATCH] D27632: Add Formatv() versions of all our printf style formatting functions
On 10 December 2016 at 18:09, Zachary Turner wrote:
> To elaborate about member function vs format provider, decoupling types from
> the way they're formatted seems like a good design practice in general. For
> example, you might want to add support for formatting a class which you
> don't have the code to. Sure, you can do it one way whenever possible and
> another way whenever it's not possible, but since tight coupling leads to
> more fragile code as a general rule, it seems better to prefer the loose
> coupling whenever possible.
Thanks for explaining this. Loose coupling sounds very reasonable.
Reading the docs again, they do seem to imply that this is the
preferred method. I think what confused me is that I started off with
the source code, and that one searches for the member function first.
:)
>
> On the other hand, there are certain times when you *must* use a
> member-based formatter. For example, when something already has a formatter
> defined for it (either via member syntax or format_provider specialization)
> and you want to change the behavior. A good example of this is the
> `fmt_repeat` adaptor I use in this patch. int already has a formatter
> defined for it, so if we want to repeat an int 10 times, we have no way to
> do that. So we define a class `fmt_repeat` and give that a format member
> function, then instead of saying formatv("{0}", 7) we say formatv("{0}",
> fmt_repeat(7, 10));
In this case, I have a feeling that the search for a member function
was implemented in a more complicated way than necessary (and I have
made it more complicated without understanding the reasoning behind
it). But that's a different discussion. I'll try to send you a patch
simplifying it.
> Another point regarding F and D styles vs F.GetFilename() and
> F.GetDirectory(). One of the original design goals was brevity, because
> usually brevity helps readability. To that end, I find
>
> formatv("Dir: {0:D}, File: {0:F}", F);
>
> more readable than
>
> formatv("Dir: {0}, File: {1}, F.GetDirectory(), F.GetFilename());
>
> There's another, more subtle, advantage though. If you just use
> GetFilename() and GetDirectory(), then what do you print if the string is
> empty? Here we've got a simple string, no different from any other string,
> and an empty string is perfectly normal. With specific types such as
> FileSpec, you know more about where that string came from, so you can make
> better decisions about how you want to handle the empty case (this argument
> applies to anything, not just strings, btw). So now you either have to
> modify the core string formatter so that you can do something like this to
> specify an "empty" value:
>
> formatv("Dir: {0:(empty)}, File: {1:(empty)}", File.GetDirectory(),
> File.GetFilename());
>
> or, even worse, you have to do this:
>
> formatv("Dir: {0}, File: {1}, File.GetFilename().IsEmpty() ? "(empty)" :
> File.GetFilename(), F.GetDirectory().IsEmpty() ? "(empty)" :
> F.GetDirectory());
>
> both are getting further and further away from the very simple and easy to
> read
>
> formatv("Dir: {0:D}, File: {0:F}", F);
>
> and both increase the possibility for errors and inconsistencies throughout
> the code whereas with the F and D styles, you guarantee that every time you
> ever print a FileSpec, it's always going to be consistent (of course, we
> could add an override mechanism to the FileSpec formatter as well if it were
> *really* necessary, but it seems best to try to avoid it as much as
> possible)
>
Seems reasonable. I withdraw my objection. LGTM.
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r289427 - Remove some annotations from TestMultipleTargets
Author: labath
Date: Mon Dec 12 05:37:42 2016
New Revision: 289427
URL: http://llvm.org/viewvc/llvm-project?rev=289427&view=rev
Log:
Remove some annotations from TestMultipleTargets
The test passes on linux. The i386 case is already handled by
skipIfHostIncompatibleWithRemote.
Modified:
lldb/trunk/packages/Python/lldbsuite/test/api/multiple-targets/TestMultipleTargets.py
Modified:
lldb/trunk/packages/Python/lldbsuite/test/api/multiple-targets/TestMultipleTargets.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/api/multiple-targets/TestMultipleTargets.py?rev=289427&r1=289426&r2=289427&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/api/multiple-targets/TestMultipleTargets.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/api/multiple-targets/TestMultipleTargets.py
Mon Dec 12 05:37:42 2016
@@ -21,15 +21,9 @@ class TestMultipleTargets(TestBase):
@skipIfNoSBHeaders
@skipIfHostIncompatibleWithRemote
@expectedFailureAll(
-archs="i[3-6]86",
-bugnumber="multi-process-driver.cpp creates an x64 target")
-@expectedFailureAll(
-oslist=[
-"windows",
-"linux",
-"freebsd"],
+oslist=["windows", "freebsd"],
bugnumber="llvm.org/pr20282")
-def test_multiple_debuggers(self):
+def test_multiple_targets(self):
env = {self.dylibPath: self.getLLDBLibraryEnvVal()}
self.driver_exe = os.path.join(os.getcwd(), "multi-target")
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [lldb] r289223 - Fix buildbots that are failing due to this test by adding all expected fails that TestMultipleDebuggers.py has.
Hi,
I think I have already handled those failures by adding the
skipIfHostIncompatibleWithRemote decorator. I have removed linux from
this list, as it passes fine there. I have also removed the i386 case,
as I think it was put there to achieve the same thing as
skipIfHostIncompatibleWithRemote. I don't think this should have any
effect, but If it starts failing on some of your CI, could you add in
a more targeted xfail decorator?
cheers,
pavel
On 9 December 2016 at 16:25, Greg Clayton via lldb-commits
wrote:
> Author: gclayton
> Date: Fri Dec 9 10:25:13 2016
> New Revision: 289223
>
> URL: http://llvm.org/viewvc/llvm-project?rev=289223&view=rev
> Log:
> Fix buildbots that are failing due to this test by adding all expected fails
> that TestMultipleDebuggers.py has.
>
>
> Modified:
>
> lldb/trunk/packages/Python/lldbsuite/test/api/multiple-targets/TestMultipleTargets.py
>
> Modified:
> lldb/trunk/packages/Python/lldbsuite/test/api/multiple-targets/TestMultipleTargets.py
> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/api/multiple-targets/TestMultipleTargets.py?rev=289223&r1=289222&r2=289223&view=diff
> ==
> ---
> lldb/trunk/packages/Python/lldbsuite/test/api/multiple-targets/TestMultipleTargets.py
> (original)
> +++
> lldb/trunk/packages/Python/lldbsuite/test/api/multiple-targets/TestMultipleTargets.py
> Fri Dec 9 10:25:13 2016
> @@ -20,6 +20,15 @@ class TestMultipleTargets(TestBase):
>
> @skipIfNoSBHeaders
> @skipIfHostIncompatibleWithRemote
> +@expectedFailureAll(
> +archs="i[3-6]86",
> +bugnumber="multi-process-driver.cpp creates an x64 target")
> +@expectedFailureAll(
> +oslist=[
> +"windows",
> +"linux",
> +"freebsd"],
> +bugnumber="llvm.org/pr20282")
> def test_multiple_debuggers(self):
> env = {self.dylibPath: self.getLLDBLibraryEnvVal()}
>
>
>
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D27632: Add Formatv() versions of all our printf style formatting functions
clayborg added a comment.
Looking good. A few little changes and possibly supporting long option names
that can be minimally specified. See inlined comments.
Comment at: source/Host/common/FileSpec.cpp:1394
+ assert(
+ (Style.empty() || Style.equals_lower("F") || Style.equals_lower("D")) &&
+ "Invalid FileSpec style!");
If we are going to not care about case I would say we should use lower case in
our initial usages of this formatter.
This leads to another question: should we allow format strings to be specified
with longer names and that all formatv strings can be minimally specified like
the LLDB command names? Then we can choose more descriptive names like
"filename" and "directory" which can be shortened to "f" and "d" since they
minimally match. The main issue with this is if you wanted to add another
format flavor that starts with any letter that already matches, like say we
wanted to later add "filename-no-extension". We could say that the first in the
list that partially matches would always win. This would mean that when adding
support for a new flavor you would always need to add it to the end of the
list. This can help keeps things more readable in the ::format functions while
allowing users to also be explicit if they need to.
It would be nice to avoid asserts if possible in the logging ::format code as
if we ever open up the logging to users somehow (uncontrolled input), we don't
want to crash. I would rather see something in the output like "invalid format
style '' for lldb_private::FileSpec" just to be safe. The user will see
this output and it would be nice not to crash.
Comment at: source/Target/Target.cpp:1558
+error.SetErrorStringWithFormatv(
+"{0:F}[{1:x+}] can't be resolved, {0:F} is not currently loaded",
+addr_module_sp->GetFileSpec(), resolved_addr.GetFileAddress());
I would prefer us to use lower case format characters in our example code if
possible, so 'f' instead of 'F'.
https://reviews.llvm.org/D27632
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D27632: Add Formatv() versions of all our printf style formatting functions
zturner added inline comments.
Comment at: source/Host/common/FileSpec.cpp:1394
+ assert(
+ (Style.empty() || Style.equals_lower("F") || Style.equals_lower("D")) &&
+ "Invalid FileSpec style!");
clayborg wrote:
> If we are going to not care about case I would say we should use lower case
> in our initial usages of this formatter.
>
> This leads to another question: should we allow format strings to be
> specified with longer names and that all formatv strings can be minimally
> specified like the LLDB command names? Then we can choose more descriptive
> names like "filename" and "directory" which can be shortened to "f" and "d"
> since they minimally match. The main issue with this is if you wanted to add
> another format flavor that starts with any letter that already matches, like
> say we wanted to later add "filename-no-extension". We could say that the
> first in the list that partially matches would always win. This would mean
> that when adding support for a new flavor you would always need to add it to
> the end of the list. This can help keeps things more readable in the ::format
> functions while allowing users to also be explicit if they need to.
>
> It would be nice to avoid asserts if possible in the logging ::format code as
> if we ever open up the logging to users somehow (uncontrolled input), we
> don't want to crash. I would rather see something in the output like "invalid
> format style '' for lldb_private::FileSpec" just to be safe. The user
> will see this output and it would be nice not to crash.
I'm sort of ambivalent about long option names in the way you suggest. It
definitely allows for less cryptic format strings, but on the other hand with
our 80-column limit, with run the risk of leading to additional levels of
wrapping which could reduce readability. That said, it's easy to modify these
formatters, so maybe we could start with short only, and then re-evaluate after
it starts getting some usage? Would give people a chance to build up a
stronger opinion one way or the other.
As for asserts, I don't think it should be an issue here. The reason I say
this is because the assert is compiled out in release mode, so the assert
itself will never be the cause of a crash for the user. The only way it could
crash is if the code that followed did not perform gracefully under the
condition that triggered the assert to fire in the first place.
The assert here is used only to notify the programmer that they've made a
mistake in their debug build, but in a normal build it will fall back to using
the default Dir + Separator + Filename format if anything in the format string
is unrecognized.
I prefer this to adding additional conditional branches, because printing
something sane is better than printing "Unknown Format String" in a log file.
https://reviews.llvm.org/D27632
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D27632: Add Formatv() versions of all our printf style formatting functions
clayborg added inline comments.
Comment at: source/Host/common/FileSpec.cpp:1394
+ assert(
+ (Style.empty() || Style.equals_lower("F") || Style.equals_lower("D")) &&
+ "Invalid FileSpec style!");
zturner wrote:
> clayborg wrote:
> > If we are going to not care about case I would say we should use lower case
> > in our initial usages of this formatter.
> >
> > This leads to another question: should we allow format strings to be
> > specified with longer names and that all formatv strings can be minimally
> > specified like the LLDB command names? Then we can choose more descriptive
> > names like "filename" and "directory" which can be shortened to "f" and
> > "d" since they minimally match. The main issue with this is if you wanted
> > to add another format flavor that starts with any letter that already
> > matches, like say we wanted to later add "filename-no-extension". We could
> > say that the first in the list that partially matches would always win.
> > This would mean that when adding support for a new flavor you would always
> > need to add it to the end of the list. This can help keeps things more
> > readable in the ::format functions while allowing users to also be explicit
> > if they need to.
> >
> > It would be nice to avoid asserts if possible in the logging ::format code
> > as if we ever open up the logging to users somehow (uncontrolled input), we
> > don't want to crash. I would rather see something in the output like
> > "invalid format style '' for lldb_private::FileSpec" just to be safe.
> > The user will see this output and it would be nice not to crash.
> I'm sort of ambivalent about long option names in the way you suggest. It
> definitely allows for less cryptic format strings, but on the other hand with
> our 80-column limit, with run the risk of leading to additional levels of
> wrapping which could reduce readability. That said, it's easy to modify
> these formatters, so maybe we could start with short only, and then
> re-evaluate after it starts getting some usage? Would give people a chance
> to build up a stronger opinion one way or the other.
>
> As for asserts, I don't think it should be an issue here. The reason I say
> this is because the assert is compiled out in release mode, so the assert
> itself will never be the cause of a crash for the user. The only way it
> could crash is if the code that followed did not perform gracefully under the
> condition that triggered the assert to fire in the first place.
>
> The assert here is used only to notify the programmer that they've made a
> mistake in their debug build, but in a normal build it will fall back to
> using the default Dir + Separator + Filename format if anything in the format
> string is unrecognized.
>
> I prefer this to adding additional conditional branches, because printing
> something sane is better than printing "Unknown Format String" in a log file.
>
>
I am saying that we add long format name support in now only in the ::format()
functions but use them with the minimal characters on our code when logging.
This would avoid any 80 char limitations when using them, but keep the
::format() functions more readable.
I am fine with the assert being there if the code still is designed to function
when the assert isn't there. LLVM tends to say asserts are invariants and the
code isn't expect to function when the asserts are off, so as long as we avoid
avoid this in LLDB I am fine (use asserts for alerting, but code around it).
Comment at: source/Host/common/FileSpec.cpp:1401
+ if (dir.empty() && file.empty()) {
+Stream << "(empty)";
+return;
Do we want all strings and classes that don't have valid state to print
"(empty)"? If so maybe we build in something into formatv like:
```
Stream << formatv::empty();
```
This would allow us to get a consistent output from everyone when their objects
are invalid.
https://reviews.llvm.org/D27632
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D27632: Add Formatv() versions of all our printf style formatting functions
zturner added inline comments.
Comment at: source/Host/common/FileSpec.cpp:1394
+ assert(
+ (Style.empty() || Style.equals_lower("F") || Style.equals_lower("D")) &&
+ "Invalid FileSpec style!");
clayborg wrote:
> zturner wrote:
> > clayborg wrote:
> > > If we are going to not care about case I would say we should use lower
> > > case in our initial usages of this formatter.
> > >
> > > This leads to another question: should we allow format strings to be
> > > specified with longer names and that all formatv strings can be minimally
> > > specified like the LLDB command names? Then we can choose more
> > > descriptive names like "filename" and "directory" which can be shortened
> > > to "f" and "d" since they minimally match. The main issue with this is if
> > > you wanted to add another format flavor that starts with any letter that
> > > already matches, like say we wanted to later add "filename-no-extension".
> > > We could say that the first in the list that partially matches would
> > > always win. This would mean that when adding support for a new flavor you
> > > would always need to add it to the end of the list. This can help keeps
> > > things more readable in the ::format functions while allowing users to
> > > also be explicit if they need to.
> > >
> > > It would be nice to avoid asserts if possible in the logging ::format
> > > code as if we ever open up the logging to users somehow (uncontrolled
> > > input), we don't want to crash. I would rather see something in the
> > > output like "invalid format style '' for lldb_private::FileSpec" just
> > > to be safe. The user will see this output and it would be nice not to
> > > crash.
> > I'm sort of ambivalent about long option names in the way you suggest. It
> > definitely allows for less cryptic format strings, but on the other hand
> > with our 80-column limit, with run the risk of leading to additional levels
> > of wrapping which could reduce readability. That said, it's easy to modify
> > these formatters, so maybe we could start with short only, and then
> > re-evaluate after it starts getting some usage? Would give people a chance
> > to build up a stronger opinion one way or the other.
> >
> > As for asserts, I don't think it should be an issue here. The reason I say
> > this is because the assert is compiled out in release mode, so the assert
> > itself will never be the cause of a crash for the user. The only way it
> > could crash is if the code that followed did not perform gracefully under
> > the condition that triggered the assert to fire in the first place.
> >
> > The assert here is used only to notify the programmer that they've made a
> > mistake in their debug build, but in a normal build it will fall back to
> > using the default Dir + Separator + Filename format if anything in the
> > format string is unrecognized.
> >
> > I prefer this to adding additional conditional branches, because printing
> > something sane is better than printing "Unknown Format String" in a log
> > file.
> >
> >
> I am saying that we add long format name support in now only in the
> ::format() functions but use them with the minimal characters on our code
> when logging. This would avoid any 80 char limitations when using them, but
> keep the ::format() functions more readable.
>
> I am fine with the assert being there if the code still is designed to
> function when the assert isn't there. LLVM tends to say asserts are
> invariants and the code isn't expect to function when the asserts are off, so
> as long as we avoid avoid this in LLDB I am fine (use asserts for alerting,
> but code around it).
Ahh I see what you mean. I wouldn't want us to do anything like that across
the board, because we can't foresee all possible ways we might want to use it,
and I don't think we'd be able to apply this rule consistently across all types
and all formatters we'd ever make in LLDB. For example, I can imagine a
hypothetical situation where you might do `llvm::formatv("{0:pxest}") where p,
x, e, s, and t are "codes" for some specific field, and it just strings all the
results together. Then there are some situations where case matters, like when
printing integers `X` means hex with uppercase digits and `x` means hex with
lowercase digits.
https://reviews.llvm.org/D27632
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D27632: Add Formatv() versions of all our printf style formatting functions
clayborg accepted this revision. clayborg added a comment. This revision is now accepted and ready to land. So we need to formalize this in the formatv documentation before we begin wide adoption otherwise people can do what ever they want. It would be good to write this up so we get consistent implementations. But that is in here looks good enough to start with. https://reviews.llvm.org/D27632 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D27632: Add Formatv() versions of all our printf style formatting functions
zturner added a comment. Thanks. Not going to commit this just yet, as I know there was at least one concern over on llvm-dev about adopting this. So I'll give it another few days to see if the complaints remain. https://reviews.llvm.org/D27632 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D27632: Add Formatv() versions of all our printf style formatting functions
clayborg added a comment. Sounds good. Take it as my vote this is ok to start with if we get consensus https://reviews.llvm.org/D27632 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r289479 - Removing myself from code ownership file
Author: tfiala Date: Mon Dec 12 16:42:00 2016 New Revision: 289479 URL: http://llvm.org/viewvc/llvm-project?rev=289479&view=rev Log: Removing myself from code ownership file I'm transitioning away from my current employer, and I do not foresee myself spending much time on LLDB in the near future. Ideally somebody on the Google Android team takes over the gdb-remote protocol tests, and somebody with decent familiarity with the test suite infrastructure takes over the parallel test runner and test event stream portions of the Python test suite. Modified: lldb/trunk/CODE_OWNERS.txt Modified: lldb/trunk/CODE_OWNERS.txt URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/CODE_OWNERS.txt?rev=289479&r1=289478&r2=289479&view=diff == --- lldb/trunk/CODE_OWNERS.txt (original) +++ lldb/trunk/CODE_OWNERS.txt Mon Dec 12 16:42:00 2016 @@ -49,8 +49,3 @@ D: Test suite N: Pavel Labath E: lab...@google.com D: Linux, Android - -N: Todd Fiala -E: todd.fi...@gmail.com -D: Test Suite, esp. subsystems (concurrent test runners, test events, TestResults system), gdb-remote protocol tests - ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r289518 - Touch-up the markup of the DarwinLog.md documentation.
Author: jmolenda
Date: Mon Dec 12 23:54:17 2016
New Revision: 289518
URL: http://llvm.org/viewvc/llvm-project?rev=289518&view=rev
Log:
Touch-up the markup of the DarwinLog.md documentation.
Modified:
lldb/trunk/docs/structured_data/DarwinLog.md
Modified: lldb/trunk/docs/structured_data/DarwinLog.md
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/docs/structured_data/DarwinLog.md?rev=289518&r1=289517&r2=289518&view=diff
==
--- lldb/trunk/docs/structured_data/DarwinLog.md (original)
+++ lldb/trunk/docs/structured_data/DarwinLog.md Mon Dec 12 23:54:17 2016
@@ -6,7 +6,7 @@ This document describes the DarwinLog lo
## StructuredDataDarwinLog feature
-The DarwinLog feature supports logging os_log*() and NSLog() messages
+The DarwinLog feature supports logging `os_log`*() and `NSLog`() messages
to the command-line lldb console, as well as making those messages
available to LLDB clients via the event system. Starting with fall
2016 OSes, Apple platforms introduce a new fire-hose, stream-style
@@ -17,9 +17,9 @@ However, it also increases the work need
log messages are desired.
The debugserver binary has been modified to support collection of
-os_log*()/NSLog() messages, selection of which messages appear in the
+`os_log`*()/`NSLog`() messages, selection of which messages appear in the
stream, and fine-grained filtering of what gets passed on to the LLDB
-client. DarwinLog also tracks the activity chain (i.e. os_activity()
+client. DarwinLog also tracks the activity chain (i.e. `os_activity`()
hierarchy) in effect at the time the log messages were issued. The
user is able to configure a number of aspects related to the
formatting of the log message header fields.
@@ -30,11 +30,11 @@ macOS system; hence, the plugin support
clients, not just those built on an Apple platform.
StructuredDataDarwinLog implements the 'DarwinLog' feature type, and
-the plugin name for it shows up as 'darwin-log'.
+the plugin name for it shows up as `darwin-log`.
The user interface to the darwin-log support is via the following:
-* 'plugin structured-data darwin-log enable' command
+* `plugin structured-data darwin-log enable` command
This is the main entry point for enabling the command. It can be
set before launching a process or while the process is running.
@@ -55,32 +55,32 @@ The user interface to the darwin-log sup
This command is sticky. Once enabled, it will stay enabled for
future process launches.
-* 'plugin structured-data darwin-log disable' command
+* `plugin structured-data darwin-log disable` command
Executing this command disables os_log() capture in the currently
running process and signals LLDB to stop attempting to launch
new processes with DarwinLog support enabled.
-* 'settings set \
- plugin.structured-data.darwin-log.enable-on-startup'
+* `settings set
+ plugin.structured-data.darwin-log.enable-on-startup true`
and
- 'settings set \
- plugin.structured-data.darwin-log.auto-enable-options -- {options}'
+ `settings set
+ plugin.structured-data.darwin-log.auto-enable-options -- `{options}
- When enable-on-startup is set to true, then LLDB will automatically
+ When `enable-on-startup` is set to `true`, then LLDB will automatically
enable DarwinLog on startup of relevant processes. It will use the
content provided in the auto-enable-options settings as the
options to pass to the enable command.
- Note the '--' required after auto-enable-command. That is necessary
- for raw commands like settings set. The '--' will not become part
+ Note the `--` required after auto-enable-command. That is necessary
+ for raw commands like settings set. The `--` will not become part
of the options for the enable command.
### Message flow and related performance considerations
-os_log()-style collection is not free. The more data that must be
+`os_log`()-style collection is not free. The more data that must be
processed, the slower it will be. There are several knobs available
to the developer to limit how much data goes through the pipe, and how
much data ultimately goes over the wire to the LLDB client. The
@@ -91,12 +91,12 @@ The flow of data looks like the followin
1. Data comes into debugserver from the low-level OS facility that
receives log messages. The data that comes through this pipe can
- be limited or expanded by the '--debug', '--info' and
- '--all-processes' options of the 'plugin structured-data darwin-log
- enable' command. options. Exclude as many categories as possible
+ be limited or expanded by the `--debug`, `--info` and
+ `--all-processes` options of the `plugin structured-data darwin-log
+ enable` command options. Exclude as many categories as possible
here (also the default). The knobs here are very coarse - for
- example, whether to include os_log_info()-level or
- os_log_debug()-level i
[Lldb-commits] [lldb] r289520 - Small tweaks to the markup in StructuredDataPlugins.
Author: jmolenda
Date: Mon Dec 12 23:59:24 2016
New Revision: 289520
URL: http://llvm.org/viewvc/llvm-project?rev=289520&view=rev
Log:
Small tweaks to the markup in StructuredDataPlugins.
Modified:
lldb/trunk/docs/structured_data/StructuredDataPlugins.md
Modified: lldb/trunk/docs/structured_data/StructuredDataPlugins.md
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/docs/structured_data/StructuredDataPlugins.md?rev=289520&r1=289519&r2=289520&view=diff
==
--- lldb/trunk/docs/structured_data/StructuredDataPlugins.md (original)
+++ lldb/trunk/docs/structured_data/StructuredDataPlugins.md Mon Dec 12
23:59:24 2016
@@ -3,7 +3,7 @@
## Overview
This document describes an infrastructural feature called Structured
-Data plugins. See the DarwinLog.md doc for a description of one
+Data plugins. See the `DarwinLog.md` doc for a description of one
such plugin that makes use of this feature.
## StructuredDataPlugin
@@ -39,7 +39,7 @@ StructuredDataPlugin instances have the
const StructuredData::ObjectSP &config_sp)
```
- where type_name is the feature name and config_sp points to the
+ where `type_name` is the feature name and `config_sp` points to the
configuration structured data, which may be nullptr.
* Plugins for features present in a process are notified when modules
@@ -99,7 +99,7 @@ StructuredDataPlugin instances have the
&supported_type_names)
```
-The supported_type_names specifies an array of string entries,
+The `supported_type_names` specifies an array of string entries,
where each entry specifies the name of a StructuredData feature.
* Provide a way to forward on configuration data for a feature type
@@ -129,8 +129,8 @@ StructuredDataPlugin instances have the
previously advertised. Everything else about the content of the
dictionary is entirely up to the feature.
-* StructuredDataPlugin commands show up under 'plugin structured-data
- plugin-name'.
+* StructuredDataPlugin commands show up under `plugin structured-data
+ plugin-name`.
* StructuredDataPlugin settings show up under
- 'plugin.structured-data.{plugin-name}.
+ `plugin.structured-data.{plugin-name}`.
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
