public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
* [Bug tdep/29409] New: [gdb, tdep/aarch64] FAIL: gdb.opt/inline-small-func.exp: info breakpoints
@ 2022-07-26  8:25 vries at gcc dot gnu.org
  2022-07-26  8:51 ` [Bug tdep/29409] " vries at gcc dot gnu.org
                   ` (13 more replies)
  0 siblings, 14 replies; 15+ messages in thread
From: vries at gcc dot gnu.org @ 2022-07-26  8:25 UTC (permalink / raw)
  To: gdb-prs

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.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* [Bug tdep/29409] [gdb, tdep/aarch64] FAIL: gdb.opt/inline-small-func.exp: info breakpoints
  2022-07-26  8:25 [Bug tdep/29409] New: [gdb, tdep/aarch64] FAIL: gdb.opt/inline-small-func.exp: info breakpoints vries at gcc dot gnu.org
@ 2022-07-26  8:51 ` vries at gcc dot gnu.org
  2022-07-26  8:56 ` vries at gcc dot gnu.org
                   ` (12 subsequent siblings)
  13 siblings, 0 replies; 15+ messages in thread
From: vries at gcc dot gnu.org @ 2022-07-26  8:51 UTC (permalink / raw)
  To: gdb-prs

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

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aburgess at redhat dot com,
                   |                            |luis.machado at arm dot com

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
We have these different reliability tests:

i386 / amd64:
...
      if (post_prologue_pc
          && (cust != NULL
              && cust->producer () != NULL
              && (producer_is_llvm (cust->producer ())
              || producer_is_icc_ge_19 (cust->producer ()))))
        return std::max (start_pc, post_prologue_pc);
...

arm:
...
      if (post_prologue_pc
          && (cust == NULL
              || cust->producer () == NULL
              || startswith (cust->producer (), "GNU ")
              || producer_is_llvm (cust->producer ())))
        return post_prologue_pc;
...

I wonder if it's a good idea to do this in target-dependent code.  That is, do
these guarantees by the compilers work only for specific targets?

Perhaps it's a better to move these tests to common code, and let targets
specify exceptions on it.

Note btw that with arm cust == nullptr and cust->producer () == nullptr are
reasons to trust the skip_prologue_using_sal result, in contrast with i386 /
amd64.

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* [Bug tdep/29409] [gdb, tdep/aarch64] FAIL: gdb.opt/inline-small-func.exp: info breakpoints
  2022-07-26  8:25 [Bug tdep/29409] New: [gdb, tdep/aarch64] FAIL: gdb.opt/inline-small-func.exp: info breakpoints vries at gcc dot gnu.org
  2022-07-26  8:51 ` [Bug tdep/29409] " vries at gcc dot gnu.org
@ 2022-07-26  8:56 ` vries at gcc dot gnu.org
  2022-07-26  9:05 ` vries at gcc dot gnu.org
                   ` (11 subsequent siblings)
  13 siblings, 0 replies; 15+ messages in thread
From: vries at gcc dot gnu.org @ 2022-07-26  8:56 UTC (permalink / raw)
  To: gdb-prs

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

--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
After applying this patch:
...
diff --git a/gdb/testsuite/gdb.opt/inline-small-func.h
b/gdb/testsuite/gdb.opt/inline-small
-func.h
index 66323952cf4..79c40ef824a 100644
--- a/gdb/testsuite/gdb.opt/inline-small-func.h
+++ b/gdb/testsuite/gdb.opt/inline-small-func.h
@@ -15,7 +15,7 @@

 int counter = 42;

-inline void
+static inline void __attribute__((always_inline))
 callee () {
   counter = 0; /* callee: body.  */
 }
...
I can run the test-case with clang on x86_64 and run into:
...
FAIL: gdb.opt/inline-small-func.exp: info breakpoints
...

We have insn:
...
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
...

This looks similar to the gcc info.  So, why are we supposed to trust llvm?

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* [Bug tdep/29409] [gdb, tdep/aarch64] FAIL: gdb.opt/inline-small-func.exp: info breakpoints
  2022-07-26  8:25 [Bug tdep/29409] New: [gdb, tdep/aarch64] FAIL: gdb.opt/inline-small-func.exp: info breakpoints vries at gcc dot gnu.org
  2022-07-26  8:51 ` [Bug tdep/29409] " vries at gcc dot gnu.org
  2022-07-26  8:56 ` vries at gcc dot gnu.org
@ 2022-07-26  9:05 ` vries at gcc dot gnu.org
  2022-07-26  9:12 ` luis.machado at arm dot com
                   ` (10 subsequent siblings)
  13 siblings, 0 replies; 15+ messages in thread
From: vries at gcc dot gnu.org @ 2022-07-26  9:05 UTC (permalink / raw)
  To: gdb-prs

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

--- Comment #3 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #1)
> Perhaps it's a better to move these tests to common code, and let targets
> specify exceptions on it.

Hmm, that point was already made during review
(https://sourceware.org/pipermail/gdb-patches/2012-November/097691.html ).

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* [Bug tdep/29409] [gdb, tdep/aarch64] FAIL: gdb.opt/inline-small-func.exp: info breakpoints
  2022-07-26  8:25 [Bug tdep/29409] New: [gdb, tdep/aarch64] FAIL: gdb.opt/inline-small-func.exp: info breakpoints vries at gcc dot gnu.org
                   ` (2 preceding siblings ...)
  2022-07-26  9:05 ` vries at gcc dot gnu.org
@ 2022-07-26  9:12 ` luis.machado at arm dot com
  2022-07-26 10:58 ` vries at gcc dot gnu.org
                   ` (9 subsequent siblings)
  13 siblings, 0 replies; 15+ messages in thread
From: luis.machado at arm dot com @ 2022-07-26  9:12 UTC (permalink / raw)
  To: gdb-prs

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

--- Comment #4 from Luis Machado <luis.machado at arm dot com> ---
Thanks. FTR, on Ubuntu 22.04 and 20.04 I don't see this. Might also be
sensitive to compiler version.

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* [Bug tdep/29409] [gdb, tdep/aarch64] FAIL: gdb.opt/inline-small-func.exp: info breakpoints
  2022-07-26  8:25 [Bug tdep/29409] New: [gdb, tdep/aarch64] FAIL: gdb.opt/inline-small-func.exp: info breakpoints vries at gcc dot gnu.org
                   ` (3 preceding siblings ...)
  2022-07-26  9:12 ` luis.machado at arm dot com
@ 2022-07-26 10:58 ` vries at gcc dot gnu.org
  2022-07-26 11:14 ` vries at gcc dot gnu.org
                   ` (8 subsequent siblings)
  13 siblings, 0 replies; 15+ messages in thread
From: vries at gcc dot gnu.org @ 2022-07-26 10:58 UTC (permalink / raw)
  To: gdb-prs

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

--- Comment #5 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Luis Machado from comment #4)
> Thanks. FTR, on Ubuntu 22.04 and 20.04 I don't see this. Might also be
> sensitive to compiler version.

Yes, that's quite possible.

With gcc 7.5.0, we have:
...
$ gcc ./src/gdb/testsuite/gdb.opt/inline-small-func.c -O1 -g -c
$ objdump -d inline-small-func.o                                   

inline-small-func.o:     file format elf64-x86-64


Disassembly of section .text:

0000000000000000 <main>:
   0:   c7 05 00 00 00 00 00    movl   $0x0,0x0(%rip)        # a <main+0xa>
   7:   00 00 00 
   a:   b8 00 00 00 00          mov    $0x0,%eax
   f:   c3                      ret    
$ readelf -wL inline-small-func.o 
Contents of the .debug_line section:

CU: inline-small-func.c:
File name                     Line number    Starting address    View    Stmt
inline-small-func.c                    20                   0               x

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

inline-small-func.c:
inline-small-func.c                    23                 0xa               x
inline-small-func.c                     -                0x10
...

With gcc 8.2.1:
...
$ objdump -d inline-small-func.o  

inline-small-func.o:     file format elf64-x86-64


Disassembly of section .text:

0000000000000000 <main>:
   0:   c7 05 00 00 00 00 00    movl   $0x0,0x0(%rip)        # a <main+0xa>
   7:   00 00 00 
   a:   b8 00 00 00 00          mov    $0x0,%eax
   f:   c3                      ret    
$ readelf -wL inline-small-func.o 
Contents of the .debug_line section:

CU: inline-small-func.c:
File name                     Line number    Starting address    View    Stmt
inline-small-func.c                    20                   0               x
inline-small-func.c                    21                   0       1       x

inline-small-func.h:
inline-small-func.h                    19                   0       2       x
inline-small-func.h                    20                   0       3       x
inline-small-func.h                    20                   0       4

inline-small-func.c:
inline-small-func.c                    22                 0xa               x
inline-small-func.c                    23                 0xa       1
inline-small-func.c                     -                0x10
...

Same thing for aarch64, I've verified that using a cross compiler.

I think it's due to gcc commit 58006663903 ("[IEPM] Introduce inline entry
point markers").

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* [Bug tdep/29409] [gdb, tdep/aarch64] FAIL: gdb.opt/inline-small-func.exp: info breakpoints
  2022-07-26  8:25 [Bug tdep/29409] New: [gdb, tdep/aarch64] FAIL: gdb.opt/inline-small-func.exp: info breakpoints vries at gcc dot gnu.org
                   ` (4 preceding siblings ...)
  2022-07-26 10:58 ` vries at gcc dot gnu.org
@ 2022-07-26 11:14 ` vries at gcc dot gnu.org
  2022-07-26 12:57 ` vries at gcc dot gnu.org
                   ` (7 subsequent siblings)
  13 siblings, 0 replies; 15+ messages in thread
From: vries at gcc dot gnu.org @ 2022-07-26 11:14 UTC (permalink / raw)
  To: gdb-prs

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

--- Comment #6 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #2)
> After applying this patch:
> ...
> diff --git a/gdb/testsuite/gdb.opt/inline-small-func.h
> b/gdb/testsuite/gdb.opt/inline-small
> -func.h
> index 66323952cf4..79c40ef824a 100644
> --- a/gdb/testsuite/gdb.opt/inline-small-func.h
> +++ b/gdb/testsuite/gdb.opt/inline-small-func.h
> @@ -15,7 +15,7 @@
>  
>  int counter = 42;
>  
> -inline void
> +static inline void __attribute__((always_inline))
>  callee () {
>    counter = 0; /* callee: body.  */
>  }
> ...
> I can run the test-case with clang on x86_64 and run into:
> ...
> FAIL: gdb.opt/inline-small-func.exp: info breakpoints
> ...
> 

Well, that's with gdb 12.1.

With trunk, which includes support for prologue_end, it passes.  Yay!

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* [Bug tdep/29409] [gdb, tdep/aarch64] FAIL: gdb.opt/inline-small-func.exp: info breakpoints
  2022-07-26  8:25 [Bug tdep/29409] New: [gdb, tdep/aarch64] FAIL: gdb.opt/inline-small-func.exp: info breakpoints vries at gcc dot gnu.org
                   ` (5 preceding siblings ...)
  2022-07-26 11:14 ` vries at gcc dot gnu.org
@ 2022-07-26 12:57 ` vries at gcc dot gnu.org
  2022-07-26 13:10 ` luis.machado at arm dot com
                   ` (6 subsequent siblings)
  13 siblings, 0 replies; 15+ messages in thread
From: vries at gcc dot gnu.org @ 2022-07-26 12:57 UTC (permalink / raw)
  To: gdb-prs

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

--- Comment #7 from Tom de Vries <vries at gcc dot gnu.org> ---
Created attachment 14233
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14233&action=edit
Demonstrator patch

This patch fixes the fail for me with gcc 7.5.0, by only trusting gcc 8.1 and
later.

Interestingly, that alone was not enough, and I also needed this bit:
...
@@ -302,6 +303,8 @@ aarch64_analyze_prologue (struct gdbarch *gdbarch,
     regs[i] = pv_register (i, 0);
   pv_area stack (AARCH64_SP_REGNUM, gdbarch_addr_bit (gdbarch));

+  CORE_ADDR orig_start = start;
+
   for (; start < limit; start += 4)
     {
       uint32_t insn;
@@ -544,7 +547,7 @@ aarch64_analyze_prologue (struct gdbarch *gdbarch,
     }

   if (cache == NULL)
-    return start;
+    return seen_stack_set ? start : orig_start;

   if (pv_is_register (regs[AARCH64_FP_REGNUM], AARCH64_SP_REGNUM))
     {
@@ -583,7 +586,7 @@ aarch64_analyze_prologue (struct gdbarch *gdbarch,
        cache->saved_regs[i + regnum + AARCH64_D0_REGNUM].set_addr (offset);
     }

-  return start;
+  return seen_stack_set ? start : orig_start;
 }

 static CORE_ADDR
...
which is roughly equivalent with this bit for amd64:
...
  if (cache.frameless_p)
    return start_pc;
...

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* [Bug tdep/29409] [gdb, tdep/aarch64] FAIL: gdb.opt/inline-small-func.exp: info breakpoints
  2022-07-26  8:25 [Bug tdep/29409] New: [gdb, tdep/aarch64] FAIL: gdb.opt/inline-small-func.exp: info breakpoints vries at gcc dot gnu.org
                   ` (6 preceding siblings ...)
  2022-07-26 12:57 ` vries at gcc dot gnu.org
@ 2022-07-26 13:10 ` luis.machado at arm dot com
  2022-07-26 13:36 ` vries at gcc dot gnu.org
                   ` (5 subsequent siblings)
  13 siblings, 0 replies; 15+ messages in thread
From: luis.machado at arm dot com @ 2022-07-26 13:10 UTC (permalink / raw)
  To: gdb-prs

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

--- Comment #8 from Luis Machado <luis.machado at arm dot com> ---
Interesting. The patch makes sense to me. We might've missed a couple spots
where the stack adjustments weren't being taken into consideration.

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* [Bug tdep/29409] [gdb, tdep/aarch64] FAIL: gdb.opt/inline-small-func.exp: info breakpoints
  2022-07-26  8:25 [Bug tdep/29409] New: [gdb, tdep/aarch64] FAIL: gdb.opt/inline-small-func.exp: info breakpoints vries at gcc dot gnu.org
                   ` (7 preceding siblings ...)
  2022-07-26 13:10 ` luis.machado at arm dot com
@ 2022-07-26 13:36 ` vries at gcc dot gnu.org
  2022-07-26 13:58 ` luis.machado at arm dot com
                   ` (4 subsequent siblings)
  13 siblings, 0 replies; 15+ messages in thread
From: vries at gcc dot gnu.org @ 2022-07-26 13:36 UTC (permalink / raw)
  To: gdb-prs

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

--- Comment #9 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #7)
> Interestingly, that alone was not enough, and I also needed this bit:
> ...
> @@ -302,6 +303,8 @@ aarch64_analyze_prologue (struct gdbarch *gdbarch,
>      regs[i] = pv_register (i, 0);
>    pv_area stack (AARCH64_SP_REGNUM, gdbarch_addr_bit (gdbarch));
>  
> +  CORE_ADDR orig_start = start;
> +
>    for (; start < limit; start += 4)
>      {
>        uint32_t insn;
> @@ -544,7 +547,7 @@ aarch64_analyze_prologue (struct gdbarch *gdbarch,
>      }
>  
>    if (cache == NULL)
> -    return start;
> +    return seen_stack_set ? start : orig_start;
>  
>    if (pv_is_register (regs[AARCH64_FP_REGNUM], AARCH64_SP_REGNUM))
>      {
> @@ -583,7 +586,7 @@ aarch64_analyze_prologue (struct gdbarch *gdbarch,
>         cache->saved_regs[i + regnum + AARCH64_D0_REGNUM].set_addr (offset);
>      }
>  
> -  return start;
> +  return seen_stack_set ? start : orig_start;
>  }
>  
>  static CORE_ADDR
> ...
> which is roughly equivalent with this bit for amd64:
> ...
>   if (cache.frameless_p)
>     return start_pc;
> ...

Hmm, this seems to break (in test-case gdb.base/call-rt-st.exp) returning
0x4008e0 for:
...
00000000004008dc <loop_count>: 
  4008dc:       d10043ff        sub     sp, sp, #0x10
  4008e0:       b9000fff        str     wzr, [sp, #12]
  4008e4:       14000004        b       4008f4 <loop_count+0x18>
...
and this fixes it:
...
@@ -336,7 +339,8 @@ aarch64_analyze_prologue (struct gdbarch *gdbarch,
            }                                                                   

          /* Did we move SP to FP?  */                                          
-         if (rn == AARCH64_SP_REGNUM && rd == AARCH64_FP_REGNUM)               
+         if (rn == AARCH64_SP_REGNUM                                           
+             && (rd == AARCH64_FP_REGNUM || rd == AARCH64_SP_REGNUM))          
            seen_stack_set = true;                                              
        }                                                                       
       else if (inst.opcode->iclass == pcreladdr                                
...
but I'm not sure about this.  Maybe !frameless_p and seen_stack_set are
different concepts and need to be tracked separately?

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* [Bug tdep/29409] [gdb, tdep/aarch64] FAIL: gdb.opt/inline-small-func.exp: info breakpoints
  2022-07-26  8:25 [Bug tdep/29409] New: [gdb, tdep/aarch64] FAIL: gdb.opt/inline-small-func.exp: info breakpoints vries at gcc dot gnu.org
                   ` (8 preceding siblings ...)
  2022-07-26 13:36 ` vries at gcc dot gnu.org
@ 2022-07-26 13:58 ` luis.machado at arm dot com
  2022-07-26 14:47 ` vries at gcc dot gnu.org
                   ` (3 subsequent siblings)
  13 siblings, 0 replies; 15+ messages in thread
From: luis.machado at arm dot com @ 2022-07-26 13:58 UTC (permalink / raw)
  To: gdb-prs

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

--- Comment #10 from Luis Machado <luis.machado at arm dot com> ---
I don't see the regression with gdb.base/call-rt-st.exp, but I see
gdb.dwarf2/dw2-dir-file-name.exp failing.

Looks like a fragile bit of code.

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* [Bug tdep/29409] [gdb, tdep/aarch64] FAIL: gdb.opt/inline-small-func.exp: info breakpoints
  2022-07-26  8:25 [Bug tdep/29409] New: [gdb, tdep/aarch64] FAIL: gdb.opt/inline-small-func.exp: info breakpoints vries at gcc dot gnu.org
                   ` (9 preceding siblings ...)
  2022-07-26 13:58 ` luis.machado at arm dot com
@ 2022-07-26 14:47 ` vries at gcc dot gnu.org
  2022-07-26 15:30 ` vries at gcc dot gnu.org
                   ` (2 subsequent siblings)
  13 siblings, 0 replies; 15+ messages in thread
From: vries at gcc dot gnu.org @ 2022-07-26 14:47 UTC (permalink / raw)
  To: gdb-prs

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

--- Comment #11 from Tom de Vries <vries at gcc dot gnu.org> ---
Another regression, test-case gdb.base/store.exp, insns:
...
00000000004005e4 <add_charest>:
  4005e4:       13001c02        sxtb    w2, w0
  4005e8:       13001c20        sxtb    w0, w1
  4005ec:       12001c41        and     w1, w2, #0xff
  4005f0:       12001c00        and     w0, w0, #0xff
  4005f4:       0b000020        add     w0, w1, w0
  4005f8:       12001c00        and     w0, w0, #0xff
  4005fc:       13001c00        sxtb    w0, w0
  400600:       d65f03c0        ret
...
and lines:
...
CU: store.c:
File name                   Line number    Starting address    View    Stmt
store.c                              14            0x4005e4               x
store.c                              15            0x4005ec               x
store.c                              16            0x400600               x
...

Without the patch, we use skip_prologue_using_sal and return 0x4005ec and
consequently line 15, which is the expected one.

With the patch, we return 0x4005e4 and consequently line 14.

Intesting question: are the two first insns part of the prologue or not?

In GCC terms, they come after NOTE_INSN_PROLOGUE_END but before
NOTE_INSN_FUNCTION_BEG and consequently have line info markers for the opening
brace '{' at line 14.

You could argue that this is a gcc bug and that the insn at 0x4005e4 should
have line 15, so something like this:
...
store.c                              14            0x4005e4               x
store.c                              15            0x4005e4               x
store.c                              16            0x400600               x
...
AFAIU, this would get us line 15 both with and without the patch.

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* [Bug tdep/29409] [gdb, tdep/aarch64] FAIL: gdb.opt/inline-small-func.exp: info breakpoints
  2022-07-26  8:25 [Bug tdep/29409] New: [gdb, tdep/aarch64] FAIL: gdb.opt/inline-small-func.exp: info breakpoints vries at gcc dot gnu.org
                   ` (10 preceding siblings ...)
  2022-07-26 14:47 ` vries at gcc dot gnu.org
@ 2022-07-26 15:30 ` vries at gcc dot gnu.org
  2022-08-10 13:50 ` vries at gcc dot gnu.org
  2022-08-11 11:59 ` vries at gcc dot gnu.org
  13 siblings, 0 replies; 15+ messages in thread
From: vries at gcc dot gnu.org @ 2022-07-26 15:30 UTC (permalink / raw)
  To: gdb-prs

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

--- Comment #12 from Tom de Vries <vries at gcc dot gnu.org> ---
A less aggressive fix is:
...
+  int major, minor, opt;
+  if (producer_is_gcc (cust->producer (), &major, &minor, &opt))
+    {
+      if (opt == 0)
+       return true;
+      return version_is_at_least (major, minor, 8, 1);
+    }
...
which fixes the regression in gdb.base/store.exp, while still fixing
gdb.opt/inline-small-func.exp.

Doesn't address the gdb.dwarf2/dw2-dir-file-name.exp yet though.

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* [Bug tdep/29409] [gdb, tdep/aarch64] FAIL: gdb.opt/inline-small-func.exp: info breakpoints
  2022-07-26  8:25 [Bug tdep/29409] New: [gdb, tdep/aarch64] FAIL: gdb.opt/inline-small-func.exp: info breakpoints vries at gcc dot gnu.org
                   ` (11 preceding siblings ...)
  2022-07-26 15:30 ` vries at gcc dot gnu.org
@ 2022-08-10 13:50 ` vries at gcc dot gnu.org
  2022-08-11 11:59 ` vries at gcc dot gnu.org
  13 siblings, 0 replies; 15+ messages in thread
From: vries at gcc dot gnu.org @ 2022-08-10 13:50 UTC (permalink / raw)
  To: gdb-prs

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

--- Comment #13 from Tom de Vries <vries at gcc dot gnu.org> ---
https://sourceware.org/pipermail/gdb-patches/2022-August/191343.html

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* [Bug tdep/29409] [gdb, tdep/aarch64] FAIL: gdb.opt/inline-small-func.exp: info breakpoints
  2022-07-26  8:25 [Bug tdep/29409] New: [gdb, tdep/aarch64] FAIL: gdb.opt/inline-small-func.exp: info breakpoints vries at gcc dot gnu.org
                   ` (12 preceding siblings ...)
  2022-08-10 13:50 ` vries at gcc dot gnu.org
@ 2022-08-11 11:59 ` vries at gcc dot gnu.org
  13 siblings, 0 replies; 15+ messages in thread
From: vries at gcc dot gnu.org @ 2022-08-11 11:59 UTC (permalink / raw)
  To: gdb-prs

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

--- Comment #14 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #12)
> Doesn't address the gdb.dwarf2/dw2-dir-file-name.exp yet though.

https://sourceware.org/pipermail/gdb-patches/2022-August/191357.html

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2022-08-11 11:59 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-07-26  8:25 [Bug tdep/29409] New: [gdb, tdep/aarch64] FAIL: gdb.opt/inline-small-func.exp: info breakpoints vries at gcc dot gnu.org
2022-07-26  8:51 ` [Bug tdep/29409] " vries at gcc dot gnu.org
2022-07-26  8:56 ` vries at gcc dot gnu.org
2022-07-26  9:05 ` vries at gcc dot gnu.org
2022-07-26  9:12 ` luis.machado at arm dot com
2022-07-26 10:58 ` vries at gcc dot gnu.org
2022-07-26 11:14 ` vries at gcc dot gnu.org
2022-07-26 12:57 ` vries at gcc dot gnu.org
2022-07-26 13:10 ` luis.machado at arm dot com
2022-07-26 13:36 ` vries at gcc dot gnu.org
2022-07-26 13:58 ` luis.machado at arm dot com
2022-07-26 14:47 ` vries at gcc dot gnu.org
2022-07-26 15:30 ` vries at gcc dot gnu.org
2022-08-10 13:50 ` vries at gcc dot gnu.org
2022-08-11 11:59 ` vries at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).