Re: [PATCH 4/4] gdb/mi: extend -file-list-exec-source-files command

[Simon Marchi via Gdb-patches <gdb-patches@sourceware.org>]

On 2021-04-26 1:07 p.m., Andrew Burgess wrote:
> This commit extends the -file-list-exec-source-files command to
> support all of the features that the cli 'info sources' supports.
> 
> As this is MI the output of -file-list-exec-source-files should be
> backward compatible, though I have added an extra field into the
> output format, but I believe this is acceptable as a well behaving
> front end is free to ignore a field it doesn't understand.
> 
> As an example, the previous output might look like this:
> 
>   ^done,files=[{file="foo.c",fullname="/home/foo.c"}]
> 
> While the new output would look like:
> 
>   ^done,files=[{file="foo.c",fullname="/home/foo.c",debug-fully-read="true"}]
> 
> With the new field indicating that the source file 'foo.c' is from a
> compilation unit that GDB has fully read in.
> 
> This would allow a front end to recreate GDB's cli output format where
> the source files are split into two groups based on whether the debug
> information for the containing compilation unit has been fully read or
> not.
> 
> While -file-list-exec-source-files previously took no arguments, after
> this commit the command can _optionally_ take some arguments, as these
> are optional this should not break backward compatibility.

Your commit message is missing mentioning the new --group-by-binary
option of the MI command.  It would be useful to have an example with
and without this option, to see the new structure of the output.

In the case of the MI command, it makes sense to have --group-by-binary,
since we need to preserve backwards compatibility.

As Eli said for the doc: I don't know if "binary" is the right term.  I
would tend to say that "object file" is the right term, but it would be
good to check what term we already use elsewhere in the MI and CLI.

But in general the patch looks fine to me.

Simon