Re: [PATCH] gdb/testsuite: make gdb.base/list-nodebug.exp pass without libc symbols

[Guinevere Larsen <blarsen@redhat.com>]

On 30/01/2024 20:51, Simon Marchi wrote:
> On 1/30/24 11:48, Guinevere Larsen wrote:
>> On 30/01/2024 17:34, Simon Marchi wrote:
>>> On 1/30/24 04:30, Guinevere Larsen wrote:
>>>> Simon noticed that the test gdb.base/list-nodebug.exp would fail if
>>>> the system doesn't have debug symbols for the standard library, and
>>>> filed it as PR gdb/31290. The issue is that, if GDB finds no symbols
>>>> at all for, it takes a different exit than if it finds some symbols,
>>>> but nothing for the current location.
>>>>
>>>> This patch changes the test to accept any message, since the
>>>> important thing we're testing at this point is if GDB would crash,
>>>> not what the message is.  --- Email only:
>>>>
>>>> I tried to condense the errors instead of changing the testcase, but
>>>> I couldn't find a good way to check if there were no symbols. My
>>>> best idea was to check if the symtab that was found has a linetable,
>>>> and exit error out if no linetable is present. However, I worry that
>>>> a user may want, for example, to list a specific function and I
>>>> couldn't convince myself that the linetable was required for that,
>>>> so I decided to go this safe route instead.
>>>>
>>>> If the linetable is required, or it is at least reasonable ot
>>>> require it for listing a file, I can send the other patch instead.
>>> I guess what you are referring to here is what I complained about on
>>> IRC, which is that without debug info for libc, we get:
>>>
>>>       Breakpoint 1, 0x000055555555511d in main () (gdb) list .  No
>>>       symbol table is loaded.  Use the "file" command.
>>>
>>> and with debug info for libc, we get:
>>>
>>>       Breakpoint 1, 0x000055555555511d in main () (gdb) list .  No
>>>       debug information available to print source lines.
>>>
>>> Note that in both cases, we don't have debug info for the objfile
>>> where "main" is.  In the first case, we have zero debug info for the
>>> inferior, and in the second case, we have some debug info for the
>>> inferior (for libc), just not for the objfile containing "main".
>>>
>>> My complaint is that the difference between these two cases isn't
>>> relevant to the user, so I think the message printed should be the
>>> same in both cases.  With "list .", the user asks to print the source
>>> lines matching the current PC.  Having or not having debug info for
>>> libc doesn't matter here.  The different messages are just the result
>>> of some implementation details inside GDB.
>> Yes that's exactly what I was referring to. It was bothering me for
>> longer than that, though.
>>
>> My analysis of the problem is that list_command uses
>> get_current_source_symtab_and_line, which will always return _some_
>> symtab if there are any to be found, and will error out otherwise.
>> When it errors out (no libc debuginfo), we get the "No symbol table is
>> loaded" message. When it doesn't (with libc debuginfo) it will return
>> the symtab for libc, list_command will continue going and find the
>> current symtab and line through find_pc_line, and if there is no
>> symtab for the current we get the new error.
>>
>> Catching the error from get_current_source_symtab_and_line doesn't
>> sound too difficult, but I also wanted to avoid a situation where you
>> try "list" in that situation and GDB attempts to print libc lines
>> instead of main. I accidentally forgot that this wasn't part of what
>> we talked about on IRC, oops. The difficulty comes from figuring out
>> how we should figure out if the symtab that
>> get_current_source_symtab_and_line returns the correct symtab, and one
>> with debuginfo. My guess for checking if a symtab has debuginfo was to
>> see if it has a linetable, but I wasn't sure if that was a correct
>> assumption, and we still have the issue of a wrong symtab to deal
>> with, which wasn't trivial.
> What I was wondering when looking at it the other day is: why do we need
> to call get_current_source_symtab_and_line at all in a case where we
> don't care about the "current" location?

"current" is a poorly defined term in this context. what the `.` 
argument means with "current" is point of execution of the inferior, 
what get_current_source_symtab_and_line means by "current" is the 
location that is being printed.

I say this based on the fact that list with no arguments or with '+' use 
this "current" sal to continue printing the file.

>
> Early in the function, we have:
>
>    symtab_and_line cursal = get_current_source_symtab_and_line ();
>
> But in the `else if (arg[0] == '.')` portion of the function, it looks
> like we override `cursal` with something else.  So, it is possible to
> call get_current_source_symtab_and_line only in the scopes that actually
> require it?

As I mentioned, this gets used by no arg and '+', but I'm not sure if it 
is necessary. We can define cursal only when first printing and for '.', 
using get_last_line_printed for the rest.

That's besides the point, the important part is that this is the only 
location (other than '.' recently added) that is able to tell if the 
inferior has debuginfo, so we have to handle its error somewhere if we 
want to have a single message for all list errors.

> Simon
>

-- 
Cheers,
Guinevere Larsen
She/Her/Hers