Re: [PATCH v3 1/2] gdb/record: print frame information when exiting a recursive call

[Kevin Buettner <kevinb@redhat.com>]

On Wed, 27 Sep 2023 16:22:31 -0700
Kevin Buettner <kevinb@redhat.com> wrote:

> I'll now do some actual debugging, comparing what happens with and
> without Gwen's patch...

I think I understand what's going on now.  This part of the
patch...

    diff --git a/gdb/infrun.c b/gdb/infrun.c
    index 4730d290442..3491327422d 100644
    --- a/gdb/infrun.c
    +++ b/gdb/infrun.c
    @@ -6923,6 +6923,11 @@ process_event_stop_test (struct execution_control_state *ecs)
       frame = get_current_frame ();
       gdbarch = get_frame_arch (frame);
     
    +  /* Shorthand to make if statements smaller.  */
    +  struct frame_id original_frame_id
    +    = ecs->event_thread->control.step_frame_id;
    +  struct frame_id curr_frame_id = get_frame_id (get_current_frame ());
    +
       switch (what.main_action)
	 {
	 case BPSTAT_WHAT_SET_LONGJMP_RESUME:

...is causing get_frame_id() to be called in situations where it might
not have been called before.  For the test case in question, it's
causing glibc's symbols to be loaded - they weren't before.  If the
new code is either removed or moved to a location later in the
function, then glibc's symbols aren't loaded.

Is this a problem?

For most (almost all?) debugging scenarios, this will merely cause
some symbols to be loaded somewhat earlier in the debugging session
than they would have been otherwise.  Therefore, I don't think it's a
problem.  However, if someone has a different point of view, I'd like
to hear it...

How should we fix the regresssion?

The problematic command in gdb.dwarf2/dw2-out-of-range-end-of-seq.exp
is:

    maint info line-table main.c$

The 'main.c$' part of it is actually a regular expression.  Due
to the fact that glibc has been loaded earlier than it had been
in the past, this RE is matching main.c, which is what we want,
but also textdomain.c and support_test_main.c, which we don't.
These latter two files are from glibc.  The relevant lines from
the log file are as follows:

    (gdb) maint info line-table main.c$
    objfile: /mesquite2/sourceware-git/f38-review/bld/gdb/testsuite/outputs/gdb.dwarf2/dw2-out-of-range-end-of-seq/dw2-out-of-range-end-of-seq ((struct objfile *) 0x2273d50)
    compunit_symtab: main.c ((struct compunit_symtab *) 0x2267b80)
    symtab: /mesquite2/sourceware-git/worktree-review/gdb/testsuite/gdb.dwarf2/main.c ((struct symtab *) 0x2267c00)
    linetable: ((struct linetable *) 0x2267e20):
    INDEX  LINE   REL-ADDRESS        UNREL-ADDRESS      IS-STMT PROLOGUE-END 
    0      1      0x0000000000401106 0x0000000000401106 Y                    
    1      END    0x0000000000401111 0x0000000000401111 Y                    

    objfile: /usr/lib/debug/usr/lib64/libc.so.6-2.37-5.fc38.x86_64.debug ((struct objfile *) 0x23eecc0)
    compunit_symtab: <unknown> ((struct compunit_symtab *) 0x2c47a50)
    symtab: /usr/src/debug/glibc-2.37-5.fc38.x86_64/intl/textdomain.c ((struct symtab *) 0x2c71530)
    linetable: ((struct linetable *) 0x0):
    No line table.

    objfile: /usr/lib/debug/usr/lib64/libc.so.6-2.37-5.fc38.x86_64.debug ((struct objfile *) 0x23eecc0)
    compunit_symtab: <unknown> ((struct compunit_symtab *) 0x2c47a50)
    symtab: /usr/src/debug/glibc-2.37-5.fc38.x86_64/support/support_test_main.c ((struct symtab *) 0x2c87410)
    linetable: ((struct linetable *) 0x0):
    No line table.

If the command is changed to "maint info line-table \bmain.c$", the
word boundary anchor \b will cause only main.c to be matched.

(Ideally, the .  would also be escaped with '\' so that it would only
match a literal .  (period) and not any character.)

Kevin