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).