* How to disable GDB backtrace new behavior of including disassembly in backtrace ?
@ 2019-12-13 12:10 William Tambe
2019-12-13 19:48 ` Simon Marchi
0 siblings, 1 reply; 3+ messages in thread
From: William Tambe @ 2019-12-13 12:10 UTC (permalink / raw)
To: gdb
How to disable GDB backtrace new behavior of including disassembly in
backtrace ?
I have built GDB 8.3 and here is an example of output that I now see:
bt
#0 0x0005ed42 in set_next_entity (se=<optimized out>,
cfs_rq=<optimized out>) at /linux/kernel/sched/fair.c:6844
0x0005ed38 <pick_next_task_fair+492>: 80 74 li8 %7, 0x4 # 4
0x0005ed3a <pick_next_task_fair+494>: b8 70 add %7, %sp
0x0005ed3c <pick_next_task_fair+496>: ea 37 ld32 %3, %7
0x0005ed3e <pick_next_task_fair+498>: c7 13 cpy %1, %3
0x0005ed40 <pick_next_task_fair+500>: 92 10 inc8 %1, 32 # 0x20
=> 0x0005ed42 <pick_next_task_fair+502>: ea 11 ld32 %1, %1
0x0005ed44 <pick_next_task_fair+504>: ea 50 ld32 %5, %sp
0x0005ed46 <pick_next_task_fair+506>: e0 d0 gip %sr
0x0005ed48 <pick_next_task_fair+508>: a2 d0 4e 00 00 00
inc32 %sr, 78 # 0x4e
0x0005ed4e <pick_next_task_fair+514>: d1 1d jnz %1, %sr
#1 pick_next_task_fair (rq=<optimized out>, prev=<optimized out>,
rf=<optimized out>) at /linux/kernel/sched/fair.c:6844
Using an earlier version of GDB would have just shown two lines
without disassembly; ie:
bt
#0 0x0005ed42 in set_next_entity (se=<optimized out>,
cfs_rq=<optimized out>) at /linux/kernel/sched/fair.c:6844
#1 pick_next_task_fair (rq=<optimized out>, prev=<optimized out>,
rf=<optimized out>) at /linux/kernel/sched/fair.c:6844
How can I restore the GDB old behavior when using backtrace ?
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: How to disable GDB backtrace new behavior of including disassembly in backtrace ?
2019-12-13 12:10 How to disable GDB backtrace new behavior of including disassembly in backtrace ? William Tambe
@ 2019-12-13 19:48 ` Simon Marchi
2019-12-24 12:30 ` William Tambe
0 siblings, 1 reply; 3+ messages in thread
From: Simon Marchi @ 2019-12-13 19:48 UTC (permalink / raw)
To: William Tambe, gdb
On 2019-12-13 7:09 a.m., William Tambe wrote:
> How to disable GDB backtrace new behavior of including disassembly in
> backtrace ?
>
> I have built GDB 8.3 and here is an example of output that I now see:
>
> bt
> #0 0x0005ed42 in set_next_entity (se=<optimized out>,
> cfs_rq=<optimized out>) at /linux/kernel/sched/fair.c:6844
> 0x0005ed38 <pick_next_task_fair+492>: 80 74 li8 %7, 0x4 # 4
> 0x0005ed3a <pick_next_task_fair+494>: b8 70 add %7, %sp
> 0x0005ed3c <pick_next_task_fair+496>: ea 37 ld32 %3, %7
> 0x0005ed3e <pick_next_task_fair+498>: c7 13 cpy %1, %3
> 0x0005ed40 <pick_next_task_fair+500>: 92 10 inc8 %1, 32 # 0x20
> => 0x0005ed42 <pick_next_task_fair+502>: ea 11 ld32 %1, %1
> 0x0005ed44 <pick_next_task_fair+504>: ea 50 ld32 %5, %sp
> 0x0005ed46 <pick_next_task_fair+506>: e0 d0 gip %sr
> 0x0005ed48 <pick_next_task_fair+508>: a2 d0 4e 00 00 00
> inc32 %sr, 78 # 0x4e
> 0x0005ed4e <pick_next_task_fair+514>: d1 1d jnz %1, %sr
> #1 pick_next_task_fair (rq=<optimized out>, prev=<optimized out>,
> rf=<optimized out>) at /linux/kernel/sched/fair.c:6844
>
> Using an earlier version of GDB would have just shown two lines
> without disassembly; ie:
>
> bt
> #0 0x0005ed42 in set_next_entity (se=<optimized out>,
> cfs_rq=<optimized out>) at /linux/kernel/sched/fair.c:6844
> #1 pick_next_task_fair (rq=<optimized out>, prev=<optimized out>,
> rf=<optimized out>) at /linux/kernel/sched/fair.c:6844
>
> How can I restore the GDB old behavior when using backtrace ?
>
Hi William,
I have never seen this behavior. It's either a setting I have never
encountered, or a Python script you have loaded that is providing this
functionality (e.g. with a frame-filter).
Are you able to reproduce this behavior with another program? If so, could
you send a small reproducer (small source snippet to compile + GDB commands),
we can try it and tell you if we see the same behavior.
Simon
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: How to disable GDB backtrace new behavior of including disassembly in backtrace ?
2019-12-13 19:48 ` Simon Marchi
@ 2019-12-24 12:30 ` William Tambe
0 siblings, 0 replies; 3+ messages in thread
From: William Tambe @ 2019-12-24 12:30 UTC (permalink / raw)
To: Simon Marchi; +Cc: gdb
On Fri, Dec 13, 2019 at 2:48 PM Simon Marchi <simark@simark.ca> wrote:
>
> On 2019-12-13 7:09 a.m., William Tambe wrote:
> > How to disable GDB backtrace new behavior of including disassembly in
> > backtrace ?
> >
> > I have built GDB 8.3 and here is an example of output that I now see:
> >
> > bt
> > #0 0x0005ed42 in set_next_entity (se=<optimized out>,
> > cfs_rq=<optimized out>) at /linux/kernel/sched/fair.c:6844
> > 0x0005ed38 <pick_next_task_fair+492>: 80 74 li8 %7, 0x4 # 4
> > 0x0005ed3a <pick_next_task_fair+494>: b8 70 add %7, %sp
> > 0x0005ed3c <pick_next_task_fair+496>: ea 37 ld32 %3, %7
> > 0x0005ed3e <pick_next_task_fair+498>: c7 13 cpy %1, %3
> > 0x0005ed40 <pick_next_task_fair+500>: 92 10 inc8 %1, 32 # 0x20
> > => 0x0005ed42 <pick_next_task_fair+502>: ea 11 ld32 %1, %1
> > 0x0005ed44 <pick_next_task_fair+504>: ea 50 ld32 %5, %sp
> > 0x0005ed46 <pick_next_task_fair+506>: e0 d0 gip %sr
> > 0x0005ed48 <pick_next_task_fair+508>: a2 d0 4e 00 00 00
> > inc32 %sr, 78 # 0x4e
> > 0x0005ed4e <pick_next_task_fair+514>: d1 1d jnz %1, %sr
> > #1 pick_next_task_fair (rq=<optimized out>, prev=<optimized out>,
> > rf=<optimized out>) at /linux/kernel/sched/fair.c:6844
> >
> > Using an earlier version of GDB would have just shown two lines
> > without disassembly; ie:
> >
> > bt
> > #0 0x0005ed42 in set_next_entity (se=<optimized out>,
> > cfs_rq=<optimized out>) at /linux/kernel/sched/fair.c:6844
> > #1 pick_next_task_fair (rq=<optimized out>, prev=<optimized out>,
> > rf=<optimized out>) at /linux/kernel/sched/fair.c:6844
> >
> > How can I restore the GDB old behavior when using backtrace ?
> >
>
> Hi William,
>
> I have never seen this behavior. It's either a setting I have never
> encountered, or a Python script you have loaded that is providing this
> functionality (e.g. with a frame-filter).
I do not have a python script loaded.
What GDB command should I use to check whether I have a frame-filter ?
>
> Are you able to reproduce this behavior with another program? If so, could
> you send a small reproducer (small source snippet to compile + GDB commands),
Yes, I am able to reproduce it with any program that I compile; here
is a simple example where I can see the issue when breaking after
calling printf() and using the command backtrace.
---
#include <stdio.h>
void myfunc() {
printf("Hello world!\n");
}
void main () {
myfunc();
}
---
> we can try it and tell you if we see the same behavior.
I am using the following Binutils release that include GDB:
commit b5624945ea67525c0ba4ffec7a9d3f9366bf9071 (tag: binutils-2_33_1)
Author: Nick Clifton <nickc@redhat.com>
Date: Sat Oct 12 15:07:18 2019 +0100
Release 2.33.1
>
> Simon
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2019-12-24 12:30 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-12-13 12:10 How to disable GDB backtrace new behavior of including disassembly in backtrace ? William Tambe
2019-12-13 19:48 ` Simon Marchi
2019-12-24 12:30 ` William Tambe
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox