Re: GDB 13.2: breakpoint at wrong line after unrelated change

[Paul Smith <psmith@gnu.org>]

On Fri, 2024-03-15 at 17:11 -0400, Paul Smith via Gdb wrote:
> I can tell you that in the "good" binary case I can see that
> amd64_tdep.c:amd64_skip_prologue() is invoked which invokes
> symtab.c:skip_prologue_using_sal() as you suggested.  In fact, these
> methods are called numerous times.
> 
> In the "bad" binary case, neither of those methods is called, ever. 
> I put a gdb_printf() in both functions and in the "good" binary I see
> probably 20 invocations between starting, setting the breakpoint,
> running, and exiting: in the "bad" binary zero invocations.  I do see
> that we definitely invoke set_gdbarch_skip_prologue() with the amd64
> function pointer in both cases, so it's not that.

More details, no answers.

However, the problem is much deeper than some kind of incorrect
computation of the prologue length.  It appears to be a major
difference in the structure of the binary itself, which is weird.

The difference happens in symtab.c:find_function_start_sal_1().  When
this is called on the "good" binary,
sal.symtab->compunit()->locations_valid() is 0 so we fall through to
calling skip_prologue_sal().

In the "bad" binary, locations_valid() returns 1 instead.  This sends
us through this code starting at symtab.c:3607:

  if (funfirstline && sal.symtab != NULL
      && (sal.symtab->compunit ()->locations_valid ()
          || sal.symtab->language () == language_asm))
    {
      struct gdbarch *gdbarch = sal.symtab->compunit ()->objfile ()-
>arch ();

      sal.pc = func_addr;
      if (gdbarch_skip_entrypoint_p (gdbarch))
        sal.pc = gdbarch_skip_entrypoint (gdbarch, sal.pc);
      return sal;
    }

thus returning early.  I've checked and gdb_arch_skip_entrypoint_p()
returns null so gdbarch_skip_entrypoint() is not called.

I've also verified that all other aspects of the above if-statement
(funfirstline and sal.symtab->language()) are the same (1 and 4)
between the good and bad calls.  The difference appears to be the
return code of locations_valid().


Looking into this it appears to be something set for the entire binary,
differently between the "good" and "bad" binary.

In the "good" binary we enter read.c:process_full_comp_unit() the
passed-in dwarf2_cu value of has_loclist is false.  Because of that,
this is not called:

      if (cu->has_loclist && gcc_4_minor >= 5)
        cust->set_locations_valid (true);

and because this is not called, the locations_valid() return above is
false.

In the "bad" binary when we enter process_full_comp_unit(), the value
of has_loclist is true.  Because of this we call cust-
>set_locations_valid(true) above, and this means locations_valid()
returns true and we follow the alternate path when skip_prologue_sal()
is called.

I have to stop here for today but maybe I'll have more time later this
weekend.  If anyone has hints on how to determine why the settings of
struct dwarf2_cu is different let me know.

Cheers!