Fixed bug issue #42017

[sushmaunnibhavi]

Summary

Updates made:

Added punctuation and changed "So for instance" to "For instance"

[JDevlieghere]

Thanks. LGTM with a few nits.

lldb/docs/use/tutorial.rst

31

137

[xgupta]

Thanks @sushmaunnibhavi for the patch. Please update the revision as per the comment of @JDevlieghere. I assume you don't have commit access to commit this patch so please share your email address someone else with the commit access will commit it on you behalf.

lldb/docs/use/tutorial.rst

 double-quotes are used to protect white-spaces in an argument. If you need to
 put a backslash or double-quote character in an argument you back-slash it in
 the argument. That makes the command syntax more regular, but it also means you
 may have to quote some arguments in lldb that you wouldn't in gdb.
 
 
 Options can be placed anywhere on the command line, but if the arguments begin
 with a "-" then you have to tell lldb that you're done with options for the
-current command by adding an option termination: "--" So for instance if you
+current command by adding an option termination: "--". So for instance, if you
 want to launch a process and give the "process launch" command the
 "--stop-at-entry" option, yet you want the process you are about to launch to
 be launched with the arguments "-program_arg value", you would type:
 
 ::
 
    (lldb) process launch --stop-at-entry -- -program_arg value
 

 
 ::
 
    (lldb) breakpoint set -n "-[SKTGraphicView alignLeftEdges:]"
    (lldb) br s -n "-[SKTGraphicView alignLeftEdges:]"
 
 lldb also supports command completion for source file names, symbol names, file
 names, etc. Completion is initiated by a hitting a TAB. Individual options in a
-command can have different completers, so for instance the "--file <path>"
+command can have different completers, so for instance, the "--file <path>"
 option in "breakpoint" completes to source files, the "--shlib <path>" option
 to currently loaded shared libraries, etc. We can even do things like if you
 specify "--shlib <path>", and are completing on "--file <path>", we will only
 list source files in the shared library specified by "--shlib <path>".
 
 The individual commands are pretty extensively documented. You can use the help
 command to get an overview of which commands are available or to obtain details
 about specific commands. There is also an apropos command that will search the
 help text for all commands for a particular word and dump a summary help string
 for each matching command.
 
 Finally, there is a mechanism to construct aliases for commonly used commands.
-So for instance if you get annoyed typing:
+For instance, if you get annoyed typing:
 
 ::
 
    (lldb) breakpoint set --file foo.c --line 12
 
 you can do:
 
 ::

 since lldb reads the file ~/.lldbinit at startup, you can store all your
 aliases there and they will be generally available to you. Your aliases are
 also documented in the help command so you can remind yourself of what you've
 set up.
 
 One alias of note that we do include by popular demand is a weak emulator of
 gdb's "break" command. It doesn't try to do everything that gdb's break command
 does (for instance, it doesn't handle foo.c::bar. But it mostly works, and
-makes the transition easier. Also by popular demand, it is aliased to b. If you
+makes the transition easier. Also, by popular demand, it is aliased to b. If you
 actually want to learn the lldb command set natively, that means it will get in
 the way of the rest of the breakpoint commands. Fortunately, if you don't like
-one of our aliases, you an easily get rid of it by running (for example):
+one of our aliases, you can easily get rid of it by running (for example):
 
 ::
 
    (lldb) command unalias b
 
 I actually also do:
 
 ::
 
    (lldb) command alias b breakpoint
 
 so I can run the native lldb breakpoint command with just b
 
 The lldb command parser also supports "raw" commands, where, after command
 options are stripped off, the rest of the command string is passed
 uninterpreted to the command. This is convenient for commands whose arguments
 might be some complex expression that would be painful to backslash protect.
-For instance the "expression" command is a "raw" command for obvious reasons.
+For instance, the "expression" command is a "raw" command for obvious reasons.
 The "help" output for a command will tell you if it is "raw" or not, so you
 know what to expect. The one thing you have to watch out for is that since raw
 commands still can have options, if your command string has dashes in it,
 you'll have to indicate these are not option markers by putting "--" after the
 command name, but before your command string.
 
 lldb also has a built-in Python interpreter, which is accessible by the
 "script" command. All the functionality of the debugger is available as classes

 Note that setting a breakpoint creates a logical breakpoint, which could
 resolve to one or more locations. For instance, break by selector would set a
 breakpoint on all the methods that implement that selector in the classes in
 your program. Similarly, a file and line breakpoint might result in multiple
 locations if that file and line were inlined in different places in your code.
 
 The logical breakpoint has an integer id, and its locations have an id within
 their parent breakpoint (the two are joined by a ".", e.g. 1.1 in the example
-above.)
+above).
 
-Also the logical breakpoints remain live so that if another shared library were
+Also, the logical breakpoints remain live so that if another shared library were
 to be loaded that had another implementation of the "alignLeftEdges:" selector,
 the new location would be added to breakpoint 1 (e.g. a "1.2" breakpoint would
 be set on the newly loaded selector).
 
 The other piece of information in the breakpoint listing is whether the
 breakpoint location was resolved or not. A location gets resolved when the file
 address it corresponds to gets loaded into the program you are debugging. For
 instance if you set a breakpoint in a shared library that then gets unloaded,

 ::
 
    (lldb) breakpoint set --file foo.c --line 12
    Breakpoint created: 2: file ='foo.c', line = 12, locations = 0 (pending)
    WARNING: Unable to resolve breakpoint to any actual locations.
 
 You can delete, disable, set conditions and ignore counts either on all the
 locations generated by your logical breakpoint, or on any one of the particular
-locations your specification resolved to. For instance if we wanted to add a
+locations your specification resolved to. For instance, if we wanted to add a
 command to print a backtrace when we hit this breakpoint we could do:
 
 ::
 
    (lldb) breakpoint command add 1.1
    Enter your debugger command(s). Type 'DONE' to end.
    > bt
    > DONE
 
 By default, the breakpoint command add command takes lldb command line
 commands. You can also specify this explicitly by passing the "--command"
 option. Use "--script" if you want to implement your breakpoint command using
 the Python script instead.
 
-This is an convenient point to bring up another feature of the lldb command
+This is a convenient point to bring up another feature of the lldb command
 help. Do:
 
 ::
 
    (lldb) help break command add
    Add a set of commands to a breakpoint, to be executed whenever the breakpoint is hit.
 
    Syntax: breakpoint command add <cmd-options> <breakpt-id>