[Bug tdep/29409] New: [gdb, tdep/aarch64] FAIL: gdb.opt/inline-small-func.exp: info breakpoints

["vries at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=29409

            Bug ID: 29409
           Summary: [gdb, tdep/aarch64] FAIL:
                    gdb.opt/inline-small-func.exp: info breakpoints
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: tdep
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

I.

With aarch64, I see:
...
FAIL: gdb.opt/inline-small-func.exp: info breakpoints
...

In more detail we have:
...
(gdb) info breakpoints^M
Num     Type           Disp Enb Address            What^M
2       breakpoint     keep y   0x00000000004005ec in callee at
inline-small-func.c:23^M
(gdb) FAIL: gdb.opt/inline-small-func.exp: info breakpoints
...
while "at inline-small-func.h:20" is expected.

This passes for x86_64.

The test-case mentions problems around prologue analysis as the possible
culprit:
...
# This test simply compiles with optimization and checks that GDB can           
# do something suitable with the compiled binary.  Problems with this           
# test are most likely to occur when GDB asks the target specific code          
# to skip the prologue (gdbarch_skip_prologue).  Some targets make use          
# of skip_prologue_using_sal, which should be fine, however, some               
# targets make a poor attempt to duplicate parts of                             
# skip_prologue_using_sal, these targets could easily fail this test.           
# This is not (necessarily) a problem with this test, but could                 
# indicate a weakness with the target in question.                             
              ...

So let's compare behaviour between x86_64 and aarch64.

II.

For x86_64, we have insns:
...
00000000004004a7 <main>:
  4004a7:       c7 05 77 0b 20 00 00    movl   $0x0,0x200b77(%rip)        #
601028 <counter>
  4004ae:       00 00 00
  4004b1:       b8 00 00 00 00          mov    $0x0,%eax
  4004b6:       c3                      ret
...
and lines:
...
CU: inline-small-func.c:
File name                    Line number    Starting address    View    Stmt
inline-small-func.c                   20            0x4004a7               x

inline-small-func.h:
inline-small-func.h                   20            0x4004a7       1       x

inline-small-func.c:
inline-small-func.c                   23            0x4004b1               x
inline-small-func.c                    -            0x4004b7
...

gdbarch_skip_prologue is only ever called with address 0x4004a7, and returns
the same.

In more detail, in amd64_skip_prologue we do skip_prologue_using_sal using
func_addr 0x4004a7 and get:
...
(gdb) p /x post_prologue_pc
$7 = 0x4004b1
...

However, this line info reliability test fails:
...

      /* LLVM backend (Clang/Flang) always emits a line note before the         
         prologue and another one after.  We trust clang and newer Intel        
         compilers to emit usable line notes.  */
      if (post_prologue_pc
          && (cust != NULL
              && cust->producer () != nullptr
              && (producer_is_llvm (cust->producer ())
              || producer_is_icc_ge_19 (cust->producer ()))))
        return std::max (start_pc, post_prologue_pc);
...
so we fall back to amd64_analyze_prologue, which returns 0x4004a7, and the we
bail out due to cache.frameless_p:
...
  if (cache.frameless_p)
    return start_pc;
...


III.

For aarch64, we have insns:
...
00000000004005e4 <main>:
  4005e4:       90000100        adrp    x0, 420000
<__libc_start_main@GLIBC_2.17>
  4005e8:       b900281f        str     wzr, [x0, #40]
  4005ec:       52800000        mov     w0, #0x0                        // #0
  4005f0:       d65f03c0        ret
...
and lines:
...
CU: inline-small-func.c:
File name                      Line number    Starting address    View    Stmt
inline-small-func.c                     20            0x4005e4               x

inline-small-func.h:
inline-small-func.h                     20            0x4005e4       1       x

inline-small-func.c:
inline-small-func.c                     23            0x4005ec               x
inline-small-func.c                      -            0x4005f4
...

Again, gdbarch_skip_prologue is only ever called with the main address:
0x4005e4, but it returns 0x4005ec.

In more detail, in aarch64_skip_prologue we do skip_prologue_using_sal using
func_addr 0x4005e4 and get:
...
(gdb) p /x post_prologue_pc
$6 = 0x4005ec
...

There's no reliability test, and we return post_prologue_pc:
...
      if (post_prologue_pc != 0)
        return std::max (pc, post_prologue_pc);
...

-- 
You are receiving this mail because:
You are on the CC list for the bug.