[Bug breakpoints/15761] New: tracepoint with Linux kernel stub auto be set to disable

[Bug breakpoints/15761] New: tracepoint with Linux kernel stub auto be set to disable

[teawater at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15761

            Bug ID: 15761
           Summary: tracepoint with Linux kernel stub auto be set to
                    disable
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: breakpoints
          Assignee: unassigned at sourceware dot org
          Reporter: teawater at gmail dot com

Following is the step to reproduce this issue:
uname -r
3.2.0-49-generic
sudo gdb /usr/lib/debug/boot/vmlinux-$(uname -r)

#Conect to KGTP or another gdb stub (for example: gdb stub of qemu)
(gdb) target remote /sys/kernel/debug/gtp

(gdb) trace arch_local_irq_disable
Tracepoint 1 at 0xffffffff810041e3: arch_local_irq_disable. (289 locations)
(gdb) info tracepoints 
Num     Type           Disp Enb Address            What
1       tracepoint     keep n   <MULTIPLE>         
1.1                         y     0xffffffff810041e3 in xen_load_sp0 
                                                   at
/build/buildd/linux-3.2.0/arch/x86/include/asm/paravirt.h:881
You can see that the tracepoint 1 was auto set to disable.  If you want use it,
you need "enable" to open it.
Please note that this issue cannot be reproduced after GDB connect this stub
some times.



But I cannot reproduce this issue with new Linux kernel.  I think the reason is
the code around arch_local_irq_disable was changed:
uname -r
3.9.6-301.fc19.x86_64
(gdb) target remote /sys/kernel/debug/gtp
Remote debugging using /sys/kernel/debug/gtp
0x0000000000000000 in irq_stack_union ()
(gdb) trace arch_local_irq_disable
Tracepoint 1 at 0xffffffff8137e8d4: arch_local_irq_disable. (3 locations)
(gdb) info tracepoints 
Num     Type           Disp Enb Address            What
1       tracepoint     keep y   <MULTIPLE>         
1.1                         y     0xffffffff8137e8d4 in arch_local_irq_disable 
                                                   at
/usr/src/debug/kernel-3.9.fc19/linux-3.9.6-301.fc19.x86_64/arch/x86/include/asm/paravirt.h:838
    not installed on target
1.2                         y     0xffffffff81d04b2f in start_kernel 
                                                   at
/usr/src/debug/kernel-3.9.fc19/linux-3.9.6-301.fc19.x86_64/arch/x86/include/asm/paravirt.h:838
    not installed on target
1.3                         y     0xffffffff81d04ce3 in start_kernel 
                                                   at
/usr/src/debug/kernel-3.9.fc19/linux-3.9.6-301.fc19.x86_64/arch/x86/include/asm/paravirt.h:838
    not installed on target

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

[Bug breakpoints/15761] tracepoint with Linux kernel stub auto be set to disable

[qiyao at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=15761

Yao Qi <qiyao at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |qiyao at gcc dot gnu.org

--- Comment #1 from Yao Qi <qiyao at gcc dot gnu.org> ---
Can we get the problem *without* connecting to the remote target?

sudo gdb /usr/lib/debug/boot/vmlinux-$(uname -r)
(gdb) trace arch_local_irq_disable

or

(gdb) break arch_local_irq_disable

Is the breakpoint or tracepoint 1 still disabled while all its locations are
enabled?  If yes, it is a problem related to breakpoint, instead of a
tracepoint specific one.

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

[Bug breakpoints/15761] tracepoint with Linux kernel stub auto be set to disable

[teawater at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15761

teawater <teawater at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at redhat dot com

--- Comment #2 from teawater <teawater at gmail dot com> ---
1. To reproduce this issue.
GDB need to connect to a target first.  I tried KGTP and QEMU.

2. I cannot reproduce this issue with breakpoint.

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

[Bug breakpoints/15761] tracepoint with Linux kernel stub auto be set to disable

[qiyao at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=15761

--- Comment #3 from Yao Qi <qiyao at gcc dot gnu.org> ---
(In reply to teawater from comment #2)
> 1. To reproduce this issue.
> GDB need to connect to a target first.  I tried KGTP and QEMU.
> 
> 2. I cannot reproduce this issue with breakpoint.

OK, then, please attach kernel 3.2.0-49-generic, and list the steps to
reproduce on QEMU.

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

[Bug breakpoints/15761] tracepoint with Linux kernel stub auto be set to disable

[teawater at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15761

--- Comment #4 from teawater <teawater at gmail dot com> ---
(In reply to Yao Qi from comment #3)
> (In reply to teawater from comment #2)
> > 1. To reproduce this issue.
> > GDB need to connect to a target first.  I tried KGTP and QEMU.
> > 
> > 2. I cannot reproduce this issue with breakpoint.
> 
> OK, then, please attach kernel 3.2.0-49-generic, and list the steps to
> reproduce on QEMU.

Are you kidding?
ls -alh /usr/lib/debug/boot/vmlinux-$(uname -r)
-rw-r--r-- 1 root root 143M Jun 19 02:21
/usr/lib/debug/boot/vmlinux-3.2.0-49-generic

#Conect to KGTP or another gdb stub (for example: gdb stub of qemu)
(gdb) target remote /sys/kernel/debug/gtp

The reproduce step is same with KGTP.

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

[Bug breakpoints/15761] tracepoint with Linux kernel stub auto be set to disable

[qiyao at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=15761

--- Comment #5 from Yao Qi <qiyao at gcc dot gnu.org> ---
(In reply to teawater from comment #4)
> (In reply to Yao Qi from comment #3)
> > (In reply to teawater from comment #2)
> > > 1. To reproduce this issue.
> > > GDB need to connect to a target first.  I tried KGTP and QEMU.
> > > 
> > > 2. I cannot reproduce this issue with breakpoint.
> > 
> > OK, then, please attach kernel 3.2.0-49-generic, and list the steps to
> > reproduce on QEMU.
> 
> Are you kidding?
> ls -alh /usr/lib/debug/boot/vmlinux-$(uname -r)
> -rw-r--r-- 1 root root 143M Jun 19 02:21
> /usr/lib/debug/boot/vmlinux-3.2.0-49-generic

OK, I'll look for it somewhere else.

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

[Bug breakpoints/15761] tracepoint with Linux kernel stub auto be set to disable

[teawater at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15761

--- Comment #6 from teawater <teawater at gmail dot com> ---
(In reply to Yao Qi from comment #5)
> (In reply to teawater from comment #4)
> > (In reply to Yao Qi from comment #3)
> > > (In reply to teawater from comment #2)
> > > > 1. To reproduce this issue.
> > > > GDB need to connect to a target first.  I tried KGTP and QEMU.
> > > > 
> > > > 2. I cannot reproduce this issue with breakpoint.
> > > 
> > > OK, then, please attach kernel 3.2.0-49-generic, and list the steps to
> > > reproduce on QEMU.
> > 
> > Are you kidding?
> > ls -alh /usr/lib/debug/boot/vmlinux-$(uname -r)
> > -rw-r--r-- 1 root root 143M Jun 19 02:21
> > /usr/lib/debug/boot/vmlinux-3.2.0-49-generic
> 
> OK, I'll look for it somewhere else.

You can get it with:
wget http://ddebs.ubuntu.com/pool/main/l/linux/linux-image-$(uname
-r)-dbgsym_$(dpkg -s linux-image-$(uname -r) | grep ^Version: | sed 's/Version:
//')_$(uname -i | sed 's/x86_64/amd64/').ddeb

But I think just reproduce this kernel and qemu is a little hard for you. 
Because all of them are for Ubuntu.  You also need find kernel bzImage to let
it execution in qemu.  Maybe you still need setup a filesystem.


And if I remember is right, your are using a fedora 17.  Maybe its kernel is
not really new that can reproduce this issue with KGTP.
You can try KGTP with https://code.google.com/p/kgtp/wiki/HOWTOCN#Fedora
https://code.google.com/p/kgtp/wiki/HOWTO#Fedora.

Thanks,
Hui

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