Add support for "source info" and use it to fix MI's -symbol-list-lines.

[dawn]

Summary

This patch adds support the command 'source info' as follows:

(lldb) help source info
     Display source line information (as specified) based on the current executable's
     debug info.

Syntax: source info <cmd-options>

Command Options Usage:
  source info [-c <count>] [-s <shlib-name>] [-f <filename>] [-l <linenum>] [-e <linenum>]
  source info [-c <count>] [-s <shlib-name>] [-n <symbol>]
  source info [-c <count>] [-a <address-expression>]

       -a <address-expression> ( --address <address-expression> )
            Lookup the address and display the source information for the corresponding
            file and line.

       -c <count> ( --count <count> )
            The number of line entries to display.

       -e <linenum> ( --end-line <linenum> )
            The line number at which to stop displaying lines.

       -f <filename> ( --file <filename> )
            The file from which to display source.

       -l <linenum> ( --line <linenum> )
            The line number at which to start the displaying lines.

       -n <symbol> ( --name <symbol> )
            The name of a function whose source to display.

       -s <shlib-name> ( --shlib <shlib-name> )
            Look up the source in the given module or shared library (can be specified
            more than once).

For example:

(lldb) source info --file x.h
Lines for file x.h in compilation unit x.cpp in `x
[0x0000000100000d00-0x0000000100000d10): /Users/dawn/tmp/./x.h:10
[0x0000000100000d10-0x0000000100000d1b): /Users/dawn/tmp/./x.h:10

The new options are used to fix the MI command:

-symbol-list-lines <file>

which didn't work for header files because it called:

target modules dump line-table <file>

which only dumps line tables for a compilation unit.

The patch also fixes a bug in the error reporting when no files were supplied to the command. Previously you'd get:

(lldb) target modules dump line-table
error:
Syntax:
error: no source filenames matched any command arguments

Now you get:

error: file option must be specified.

[dawn]

Updated patch to include changes to TestHelp.py.

[jingham]

I don't think this is sufficiently different from "target modules dump line-tables" to warrant a separate command. This seems more like a candidate for a flag to "target modules dump line-tables" like --search-for-inlines or something. That would keep the command surface more manageable and also make the option more discoverable, since you can get both variants in one place.

[dawn]

In D15593#312571, @jingham wrote:

I don't think this is sufficiently different from "target modules dump line-tables" to warrant a separate command. This seems more like a candidate for a flag to "target modules dump line-tables" like --search-for-inlines or something. That would keep the command surface more manageable and also make the option more discoverable, since you can get both variants in one place.

I first thought about adding it as an option to the line-table but decided against it because the information provided by each are just too different.

Dumping the tables gives you raw output from the CU's DWARF .debug_line entries, including end sequences, all files in the compilation unit, etc.:

(lldb) target modules du line-table x.cpp
Line table for /Users/dawn/tmp/x.cpp in `x
0x0000000100000aa0: /Users/dawn/tmp/x.cpp:12
0x0000000100000ab6: /Users/dawn/tmp/x.cpp:14
0x0000000100000af2: /Users/dawn/tmp/x.cpp:16
0x0000000100000afa: /Users/dawn/tmp/x.cpp:17
[...]
0x0000000100000cc0: /Users/dawn/tmp/x.cpp:6
0x0000000100000ccb: /Users/dawn/tmp/x.cpp:8
[...]
0x0000000100000d20: /Users/dawn/tmp/./x.h:10
0x0000000100000d2c: /Users/dawn/tmp/./x.h:10
0x0000000100000d3b: /Users/dawn/tmp/./x.h:10

Whereas dumping the line entries gives you entries after they've been interpreted and sorted by lldb, and will not include any files other than the one(s) asked for:

(lldb) target modules du line-entries x.h
Lines for file x.h in compilation unit x.cpp in `x
[0x0000000100000d00-0x0000000100000d10): /Users/dawn/tmp/./x.h:10
[0x0000000100000d10-0x0000000100000d1b): /Users/dawn/tmp/./x.h:10
[0x0000000100000d20-0x0000000100000d2c): /Users/dawn/tmp/./x.h:10
[0x0000000100000d2c-0x0000000100000d3b): /Users/dawn/tmp/./x.h:10

(lldb) target modules du line-entries x.cpp
Lines for file x.cpp in compilation unit x.cpp in `x
[0x0000000100000cc0-0x0000000100000ccb): /Users/dawn/tmp/x.cpp:6
[0x0000000100000ccb-0x0000000100000cdd): /Users/dawn/tmp/x.cpp:8
[0x0000000100000cdd-0x0000000100000cf1): /Users/dawn/tmp/x.cpp:9
[0x0000000100000aa0-0x0000000100000ab6): /Users/dawn/tmp/x.cpp:12
[0x0000000100000ab6-0x0000000100000af2): /Users/dawn/tmp/x.cpp:14
[...]

I'm fine with combining the two if we can find an interface that makes sense. 'line-table' is not appropriate for the new command, and '--search-for-inlines' doesn't convey the differences. We could change 'line-table' to 'lines', but then what?

[jingham]

Okay. So it seems like there are a couple of orthogonal differences here.

1. The current behavior requires that the the source file you pass in be a compile unit. We don't search inside the line tables. So for instance

target modules dump line-tables foo.h

would currently not dump anything.

2. We dump the whole line table for the given file, not just the lines from that file.

3. We show raw vrs. cooked line entries.

So it seems like your change is adding three flags

--compile-unit-only --only-explicit-matches --show-raw

or something. The current behavior is:

--compile-unit-only true --only-explicit-matches false --show-raw true

and your command does:

--compile-unit-only false --only-explicit-matches true --show-raw false

Does that seem right. If so, then we have to decide whether it is worth the effort to be able to tweak these three independently.

[dawn]

In D15593#312665, @jingham wrote:

So it seems like your change is adding three flags

--compile-unit-only --only-explicit-matches --show-raw

or something. The current behavior is:

--compile-unit-only true --only-explicit-matches false --show-raw true

and your command does:

--compile-unit-only false --only-explicit-matches true --show-raw false

Does that seem right.

Yup.

If so, then we have to decide whether it is worth the effort to be able to tweak these three independently.

I think these flags only make sense if you could tweak them independently, but to support something like:

--compile-unit-only false --only-explicit-matches true --show-raw *true*

would be a major pain - it would mean adding a lot of extra code and interfaces for something that would only be used by this one command.

I think it's better to just have both:

target modules line-tables <cu>
target modules line-entries <file>

and if we find a need for any other combinations of the options you proposed, we can merge them at that time.

Thoughts?

[jingham]

Provided we error out appropriately I don't think we need to support all possible combinations of options. I'd happier doing it by options and not supporting the combinations that aren't worth the effort. Then if anybody really needs one of the unsupported ones, the path to adding the support will be straight-forward, even if tedious.

The options seem to me to actually explain what the variants do, whereas the two names are not going to be meaningful enough to most folks to do more than cause confusion (and force me to have to type "line-t" or "line-e".)

[dawn]

I'm only going to support the combinations:

--compile-unit-only true --only-explicit-matches false --show-raw true
--compile-unit-only false --only-explicit-matches true --show-raw false

OK?

(and force me to have to type "line-t" or "line-e".)

or force me to have to type "line-table --compile-unit-only false --only-explicit-matches true --show-raw false"?! (ugh)

[jingham]

That seems fine for now.

Note, if you use the OptionGroupOptions way of defining the new options for your command, then you can call OptionsSeen to tell you which options were actually provided by the user, so for extra credit, if --compile-unit-only is true and no other options were provided, you can set the other options to the correct values, and ditto when --compile-unit-only is false. That way for now you would only have to provide --compile-unit-only, and the others would be set to the supported combo, but if they provided an unsupported combo you could report the error appropriately.

You can also get the same effect in the table driven way of defining options by just manually marking which options have been seen in your command's SetOptionValue (just remember to clear this info in the OptionParsingStarting method.

Jim

[ki.stfu]

clang-format your changes please (there are many deviations from the coding style)

I'll check it on Linux and say if everything is OK.

source/Commands/CommandObjectTarget.cpp

1510

nit: fix indentation

1536–1537

use size_t

1541–1542

Isn't it always false?

1543

You don't need a raw pointer here, just use cu_sp.get() on line #1587

1576

!cu_header_printed

1594–1596

combine it together:

cu->FindLineEntry(start_idx + 1, ...)

2689

Please use the most popular pattern:

error.SetErrorStringWithFormat ("unrecognized option '%c'", short_option);

tools/lldb-mi/MICmdCmdSymbol.cpp

85

Could you use long-options here?

[ki.stfu]

packages/Python/lldbsuite/test/tools/lldb-mi/symbol/symbol_list_lines_inline_test.h

20

and could you pick it up at 1 line above?

[dawn]

clang-format your changes please (there are many deviations from the coding style)

I've made some fixes even though the code is no longer consistent with the rest of the file. Alas. I would love to run all of lldb through clang-format, but as we've seen, there are several options which still need to be added before we can do that (mostly relating to the formatting function declarations).

source/Commands/CommandObjectTarget.cpp

1510

This is the original code, and is consistent with the coding style of the rest of the file. It bothers me too that lldb is so schizophrenic about its coding style, but unless we fix all of lldb, I think it's best to just try and follow the style of the code around you.

Does anyone else have an opinion about this? I'll go ahead and change it, only because I see I that the new code I added didn't follow this style (oops).

1541–1542

Code elsewhere checks for it, so I assume there are cases when cu_sp can be null. Example in source/Core/SearchFilter.cpp:

for (size_t i = 0; i < num_comp_units; i++)
{
    CompUnitSP cu_sp (module_sp->GetCompileUnitAtIndex (i));
    if (cu_sp)
    {

Better safe than sorry.

1543

There are 5 uses of cu in this code, so I think it's cleaner to have a variable.

1594–1596

I'd love to have a guideline as to when to wrap lines - lldb is all over the place about this. I've tended to try to keep lines to 100.

[dawn]

Updated patch with suggestions from Ilia's review (thanks Ilia!).

[clayborg]

Man those options are complex. I really would like to see something more simple:

"--raw" dumps the line entries as you have mentioned
"--no-inlines" would omit any inline entries
"--module <module>" would only find any source file arguments in the module that is specified by full or basename (this option can be specified more than once)

The arguments are still the compile unit names (full or basenames). If there are no arguments, dump all line tables from all modules. If --module is specified, then dump all compile units from any modules that are specified.

Am I missing something?

[clayborg]

Ok, so I talked with Jim on this and this is what we came up with. I would like to see no changes made to the "target modules dump line-table" command. It is dumping complete line tables. This command is not for "find any line entries that match this file anywhere including inline references". We should make this new command into "source info". Its syntax will be:

source info --file <file> [--line <line>] [--module <module]

line is optional. This job of this command is to find all line entries that match the file and optional line and optionally look only in the modules that might have been specified (might be more than one). --file and --line can only be specified once, --module can be specified multiple times.

The functionality that you reproduced in DumpFileLines() should be replaced. This is the code that looks through all compile units and finds the line entries that is contained in:

else if (compile_unit_only == false && explicit_matches_only == true && show_raw==false)

should be replaced with a call to:

uint32_t
CompileUnit::ResolveSymbolContext
(
    const FileSpec& file_spec,
    uint32_t line,
    bool check_inlines,
    bool exact,
    uint32_t resolve_scope,
    SymbolContextList &sc_list
)

As this already does exactly what you are doing. We will need to modify CompileUnit::ResolveSymbolContext() to accept the "line" argument being zero. It will return an "sc_list" of all matches, inside each symbol context will be the LineEntry that you need.

[clayborg]

I do want to apologize to Dawn and Jim for not having chimed in earlier and causing Dawn some extra work.

[ki.stfu]

source/Commands/CommandObjectTarget.cpp

1536–1537

use it on line #1536 too

1543

That's no problem. Just replace s/cu/cu_sp/ on lines #1544, #1565, #1580, #1594, and then use cu_sp.get() on line #1586.

1594–1596

How about that?

start_idx = cu->FindLineEntry(start_idx + 1,
                              line,
                              &cu_file_spec,
                              /*exact=*/true,
                              &line_entry);

2689

nit: you forgot the dot

[ki.stfu]

tools/lldb-mi/MICmdCmdSymbol.cpp

226

Is strWantFile needed? Seems it's an auxiliary variable.

[clayborg]

Dawn, if you don't understand what I asked you to do, let me know and I can go and do the "source info" command for you, then you can modify this patch to just use the command I added. But it should be simple to just revert and changes to the original line table dumping command, and move the contents over to the new "source info" command and just make it do what you wanted it to do.

[clayborg]

Note that you won't need any of the options that you had added to the other command becuase the "source info" command will do what you wanted in the first place: find all line entries where a file and optional line is mentioned in any line tables.

[dawn]

In D15593#313342, @clayborg wrote:

Dawn, if you don't understand what I asked you to do,

Sorry for late reply - been recovering from minor surgery. I have a new patch, but I've not yet gone through all of Ilia's additional comments - will probably go ahead and upload anyway just to give you all a glimpse, as I fear there will be a few more rounds before this patch is ready.

As this already does exactly what you are doing. We will need to modify CompileUnit::ResolveSymbolContext() to accept the "line" argument being zero. It will return an "sc_list" of all matches, inside each symbol context will be the LineEntry that you need.

I didn't do this because I added support for additional options which were supported by 'source list', and needed access to the options during the loop which collects the lines. I hope you'll agree that this was the right approach after seeing the patch.

[dawn]

Replies to Ilia's comments...

source/Commands/CommandObjectTarget.cpp

1543

this no longer applies to the most recent patch.

2689

did I forget a dot?

tools/lldb-mi/MICmdCmdSymbol.cpp

226

It's no longer needed with the new code, because you'll never get a file that isn't what was asked for.

[dawn]

Hopefully folks are back from the holidays by now - can someone give this a look? Thanks in advance...

[clayborg]

So I am going to let this through because you have done all we asked and I really like the "source info" command!

But in the future when adding things for MI, please add an API in the lldb::SB layer to do what you need. Text scraping is really not the solution we should be adding into the code. Other people using MI are going to see this kind of code and think it is what they should do when implementing/fixing new/existing MI commands.

We have an API for a debugger that we are trying to make with the lldb::SB layer, so we should use it and stop ANY form of text scraping in the future. I think an API'ized version of what you are requesting here -- all line table entries for a given source file -- should be available from SBTarget and a future modification to MICmdCmdSymbol.cpp should switch over to using it.

[dawn]

In D15593#319670, @clayborg wrote:

... in the future when adding things for MI, please add an API in the lldb::SB layer to do what you need.

Thanks for not asking me to do that as part of this patch.

Text scraping is really not the solution we should be adding into the code. Other people using MI are going to see this kind of code and think it is what they should do when implementing/fixing new/existing MI commands.

I agree that MI should have used the SB layer - did anyone ask the authors about that? Because as you say, the text scraping has now become a precedent for MI commands.

We have an API for a debugger that we are trying to make with the lldb::SB layer, so we should use it and stop ANY form of text scraping in the future. I think an API'ized version of what you are requesting here -- all line table entries for a given source file -- should be available from SBTarget and a future modification to MICmdCmdSymbol.cpp should switch over to using it.

+100. Except that I think it should only apply to new code - bug fixes like this shouldn't be held back because of preexisting code.

Rewriting lldb-mi to use the SB layer would be a great project for an intern or someone who wants to get familiar with lldb. We should keep that in mind if/when folks on lldb-dev ask about how they can help out.

[dawn]

I forgot to commit updated changes to the tests:

MiSymbolTestCase.test_lldbmi_symbol_list_lines_file
HelpCommandTestCase.test_help_image_du_line_should_work

so they are failing now, but svn at llvm.org appears to be down at the moment.
I'll commit those changes as soon as svn is back up...

[dawn]

Amended patch was posted to http://reviews.llvm.org/D15904 - hopefully someone who can get to llvm.org will commit.

[dawn]

Amended patch was committed in svn r256877 (svn at lldb.org is back up now)

[labath]

Hi, the new check you have added to TestMiSymbol fails on linux: all the source lines are listed twice for some reason. I don't know if this is expected behavior (and the test needs to be fixed) or it's an bug (and the code needs to be fixed), but I have marked the test as XFAIL no pacify the buildbots.

packages/Python/lldbsuite/test/tools/lldb-mi/symbol/TestMiSymbol.py

         eline = line_number('symbol_list_lines_inline_test2.cpp', '// END_gfunc2')
         self.runCmd("-symbol-list-lines symbol_list_lines_inline_test2.cpp")
         self.expect("\^done,lines=\[\{pc=\"0x[0-9a-f]+\",line=\"%d\"\}(,\{pc=\"0x[0-9a-f]+\",line=\"3\d\"\})*,\{pc=\"0x[0-9a-f]+\",line=\"%d\"\}(,\{pc=\"0x[0-9a-f]+\",line=\"3\d\"\})*\]" % (sline, eline))
-        ##FIXME: This doesn't work for symbol_list_lines_inline_test.cpp due to clang bug llvm.org/pr24716
+        ##FIXME: This doesn't work for symbol_list_lines_inline_test.cpp due to clang bug llvm.org/pr24716 (fixed in newer versions of clang)
         ##sline = line_number('symbol_list_lines_inline_test.cpp', '// FUNC_gfunc')
         ##eline = line_number('symbol_list_lines_inline_test.cpp', '// STRUCT_s')
         ##self.runCmd("-symbol-list-lines symbol_list_lines_inline_test.cpp")
         ##self.expect("\^done,lines=\[\{pc=\"0x[0-9a-f]+\",line=\"%d\"\}(,\{pc=\"0x[0-9a-f]+\",line=\"3\d\"\})*,\{pc=\"0x[0-9a-f]+\",line=\"%d\"\}\]" % (sline, eline))
 
+        # Test that -symbol-list-lines works on header files by checking the first
+        # and last line, and making sure the other lines are under 29.
+        sline = line_number('symbol_list_lines_inline_test.h', '// FUNC_ifunc')
+        eline = line_number('symbol_list_lines_inline_test.h', '// FUNC_mfunc')
+        self.runCmd("-symbol-list-lines symbol_list_lines_inline_test.h")
+        self.expect("\^done,lines=\[\{pc=\"0x[0-9a-f]+\",line=\"%d\"\}(,\{pc=\"0x[0-9a-f]+\",line=\"\d\"\})*(,\{pc=\"0x[0-9a-f]+\",line=\"1\d\"\})*,\{pc=\"0x[0-9a-f]+\",line=\"%d\"\}(,\{pc=\"0x[0-9a-f]+\",line=\"2\d\"\})*\]" % (sline, eline))
+
         # Test that -symbol-list-lines fails when file doesn't exist
         self.runCmd("-symbol-list-lines unknown_file")
         self.expect("\^error,message=\"warning: No source filenames matched 'unknown_file'\. error: no source filenames matched any command arguments \"")

packages/Python/lldbsuite/test/tools/lldb-mi/symbol/symbol_list_lines_inline_test.h

 {
 inline int
 ifunc(int i)
-{
+{ // FUNC_ifunc
     return i;
 }
 struct S

     int
     mfunc()
     {
-        return a + b;
+        return a + b; // FUNC_mfunc
     }
 };
 extern S s;

source/Commands/CommandObjectTarget.cpp

     return num_matches;
 }
 
+static uint32_t
+DumpFileLineEntries (CommandInterpreter &interpreter,
+                     Stream &strm,
+                     Module *module,
+                     const FileSpec &file_spec,
+                     bool load_addresses)
+{
+    uint32_t num_matches = 0;
+    if (module)
+    {
+        // Look through all the compilation units (CUs) for ones that contain
+        // lines of code from this source file.
+        assert(file_spec.GetFilename().AsCString());
+        bool has_path = (file_spec.GetDirectory().AsCString() != 0);
+        int ncus = module->GetNumCompileUnits();
+        for (int i = 0; i < ncus; i++)
+        {
+            // Look for a matching source file in this CU.
+            CompUnitSP cu_sp(module->GetCompileUnitAtIndex(i));
+            if (!cu_sp)
+                continue;
+            CompileUnit *cu = cu_sp.get();
+            const FileSpecList &cu_file_list = cu->GetSupportFiles();
+            size_t file_idx = cu_file_list.FindFileIndex(0, file_spec, has_path);
+            if (file_idx == UINT32_MAX)
+                // No such file in this CU.
+                continue;
+
+            // Update the file to how it appears in the CU.
+            const FileSpec &cu_file_spec = cu_file_list.GetFileSpecAtIndex(file_idx);
+
+            // Dump all the line entries for the file in the CU.
+            const ConstString &file_spec_name = file_spec.GetFilename();
+            const ConstString &module_file_name = module->GetFileSpec().GetFilename();
+            uint32_t line = 0;
+            bool cu_header_printed = false;
+            while (true)
+            {
+                LineEntry line_entry;
+
+                // Find the lowest index of a line entry with a line equal to
+                // or higher than 'line'.
+                uint32_t start_idx = 0;
+                start_idx = cu->FindLineEntry(start_idx, line, &cu_file_spec,
+                                              /*exact=*/false, &line_entry);
+                if (start_idx == UINT32_MAX)
+                    // No more line entries for our file in this CU.
+                    break;
+
+                // Loop through to find any other entries for this line, dumping each.
+                line = line_entry.line;
+                do
+                {
+                    assert(lldb_private::FileSpec::Equal(cu_file_spec, line_entry.file, has_path));
+                    if (cu_header_printed == false)
+                    {
+                        if (num_matches > 0)
+                            strm << "\n\n";
+                        strm << "Lines for file " << file_spec_name
+                             << " in compilation unit " << cu->GetFilename()
+                             << " in `" << module_file_name << "\n";
+                        cu_header_printed = true;
+                    }
+                    line_entry.GetDescription(&strm,
+                                              lldb::eDescriptionLevelBrief,
+                                              cu,
+                                              interpreter.GetExecutionContext().GetTargetPtr(),
+                                              /*show_address_only=*/false);
+                    strm << "\n";
+                    num_matches++;
+
+                    // Anymore after this one?
+                    start_idx++;
+                    start_idx = cu->FindLineEntry(start_idx, line, &cu_file_spec,
+                                                  /*exact=*/true, &line_entry);
+                } while (start_idx != UINT32_MAX);
+
+                // Try the next higher line, starting over at start_idx 0.
+                line++;
+            }
+        }
+    }
+    return num_matches;
+}
+
 static void
 DumpFullpath (Stream &strm, const FileSpec *file_spec_ptr, uint32_t width)
 {

     }
 };
 
+class CommandObjectTargetModulesDumpLineEntries : public CommandObjectTargetModulesSourceFileAutoComplete
+{
+public:
+    CommandObjectTargetModulesDumpLineEntries (CommandInterpreter &interpreter) :
+    CommandObjectTargetModulesSourceFileAutoComplete (interpreter,
+                                                      "target modules dump line-entries",
+                                                      "Dump the line entries for one or more files.",
+                                                      NULL,
+                                                      eCommandRequiresTarget)
+    {
+    }
+
+    ~CommandObjectTargetModulesDumpLineEntries () override
+    {
+    }
+
+protected:
+    bool
+    DoExecute (Args& command, CommandReturnObject &result) override
+    {
+        Target *target = m_exe_ctx.GetTargetPtr();
+        uint32_t total_num_dumped = 0;
+
+        uint32_t addr_byte_size = target->GetArchitecture().GetAddressByteSize();
+        result.GetOutputStream().SetAddressByteSize(addr_byte_size);
+        result.GetErrorStream().SetAddressByteSize(addr_byte_size);
+
+        if (command.GetArgumentCount() == 0)
+        {
+            result.AppendErrorWithFormat ("\nSyntax: %s\n", m_cmd_syntax.c_str());
+            result.SetStatus (eReturnStatusFailed);
+        }
+        else
+        {
+            // Dump specified images (by basename or fullpath)
+            const char *arg_cstr;
+            for (int arg_idx = 0; (arg_cstr = command.GetArgumentAtIndex(arg_idx)) != NULL; ++arg_idx)
+            {
+                FileSpec file_spec(arg_cstr, false);
+
+                const ModuleList &target_modules = target->GetImages();
+                Mutex::Locker modules_locker(target_modules.GetMutex());
+                const size_t num_modules = target_modules.GetSize();
+                if (num_modules > 0)
+                {
+                    uint32_t num_dumped = 0;
+                    for (uint32_t i = 0; i<num_modules; ++i)
+                    {
+                        if (DumpFileLineEntries (m_interpreter,
+                                                 result.GetOutputStream(),
+                                                 target_modules.GetModulePointerAtIndexUnlocked(i),
+                                                 file_spec,
+                                                 m_exe_ctx.GetProcessPtr() && m_exe_ctx.GetProcessRef().IsAlive()))
+                            num_dumped++;
+                    }
+                    if (num_dumped == 0)
+                        result.AppendWarningWithFormat ("No source filenames matched '%s'.\n", arg_cstr);
+                    else
+                        total_num_dumped += num_dumped;
+                }
+            }
+        }
+
+        if (total_num_dumped > 0)
+            result.SetStatus (eReturnStatusSuccessFinishResult);
+        else
+        {
+            result.AppendError ("no source filenames matched any command arguments");
+            result.SetStatus (eReturnStatusFailed);
+        }
+        return result.Succeeded();
+    }
+};
+
 
 #pragma mark CommandObjectTargetModulesDump
 

         LoadSubCommand ("sections",    CommandObjectSP (new CommandObjectTargetModulesDumpSections (interpreter)));
         LoadSubCommand ("symfile",     CommandObjectSP (new CommandObjectTargetModulesDumpSymfile (interpreter)));
         LoadSubCommand ("line-table",  CommandObjectSP (new CommandObjectTargetModulesDumpLineTable (interpreter)));
+        LoadSubCommand ("line-entries", CommandObjectSP (new CommandObjectTargetModulesDumpLineEntries (interpreter)));
     }
 
     ~CommandObjectTargetModulesDump() override

tools/lldb-mi/MICmdCmdSymbol.cpp

     CMICMDBASE_GETOPTION(pArgFile, File, m_constStrArgNameFile);
 
     const CMIUtilString &strFilePath(pArgFile->GetValue());
-    // FIXME: this won't work for header files!  To try and use existing
-    // commands to get this to work for header files would be too slow.
-    // Instead, this code should be rewritten to use APIs and/or support
-    // should be added to lldb which would work for header files.
-    const CMIUtilString strCmd(CMIUtilString::Format("target modules dump line-table \"%s\"", strFilePath.AddSlashes().c_str()));
+    const CMIUtilString strCmd(CMIUtilString::Format("target modules dump line-entries \"%s\"", strFilePath.AddSlashes().c_str()));
 
     CMICmnLLDBDebugSessionInfo &rSessionInfo(CMICmnLLDBDebugSessionInfo::Instance());
     const lldb::ReturnStatus rtn = rSessionInfo.GetDebugger().GetCommandInterpreter().HandleCommand(strCmd.c_str(), m_lldbResult);

 {
     // Match LineEntry using regex.
     static MIUtilParse::CRegexParser g_lineentry_header_regex( 
-        "^ *Line table for (.+) in `(.+)$");
-        //                 ^1=file  ^2=module
+        "^ *Lines for file (.+) in compilation unit (.+) in `(.+)$");
+        //                 ^1=file                  ^2=cu    ^3=module
 
-    MIUtilParse::CRegexParser::Match match(3);
+    MIUtilParse::CRegexParser::Match match(4);
 
     const bool ok = g_lineentry_header_regex.Execute(input, match);
     if (ok)

 
     // Match LineEntry using regex.
     static MIUtilParse::CRegexParser g_lineentry_nocol_regex( 
-        "^ *(0x[0-9a-fA-F]+): (.+):([0-9]+)$");
+        "^ *\\[(0x[0-9a-fA-F]+)-(0x[0-9a-fA-F]+)\\): (.+):([0-9]+)$");
     static MIUtilParse::CRegexParser g_lineentry_col_regex( 
-        "^ *(0x[0-9a-fA-F]+): (.+):([0-9]+):[0-9]+$");
-        //  ^1=addr           ^2=f ^3=line ^4=:col(opt)
+        "^ *\\[(0x[0-9a-fA-F]+)-(0x[0-9a-fA-F]+)\\): (.+):([0-9]+):[0-9]+$");
+        //     ^1=start         ^2=end               ^3=f ^4=line ^5=:col(opt)
 
-    MIUtilParse::CRegexParser::Match match(5);
+    MIUtilParse::CRegexParser::Match match(6);
 
     // First try matching the LineEntry with the column,
     // then try without the column.

     if (ok)
     {
         addr = match.GetMatchAtIndex(1);
-        file = match.GetMatchAtIndex(2);
-        line = match.GetMatchAtIndex(3);
+        file = match.GetMatchAtIndex(3);
+        line = match.GetMatchAtIndex(4);
     }
     return ok;
 }

             if (!ParseLLDBLineAddressEntry(rLine.c_str(), strAddr, strFile, strLine))
                 continue;
 
-            // Skip entries which don't match the desired source.
-            if (strWantFile != strFile)
-                continue;
-
             const CMICmnMIValueConst miValueConst(strAddr);
             const CMICmnMIValueResult miValueResult("pc", miValueConst);
             CMICmnMIValueTuple miValueTuple(miValueResult);