Lines Matching refs:gdb
89 11.1 Starting the kernel under gdb
93 11.5 Attaching gdb to the kernel
2473 possible to debug it with gdb almost like any other process. It is
2475 ptraced for system call interception, so gdb can't ptrace them.
2483 ptrace proxy so that gdb works with UML, respectively.
2488 11.1. Starting the kernel under gdb
2490 You can have the kernel running under the control of gdb from the
2492 xterm with gdb running inside it. The kernel will send some commands
2493 to gdb which will leave it stopped at the beginning of start_kernel.
2506 you ^C gdb and get a backtrace, you will see the idle thread, which
2514 task.thread.extern_pid in gdb.
2522 (UML gdb) det
2531 (UML gdb) att <host pid>
2540 (UML gdb) bt
2552 (UML gdb)
2560 (UML gdb)
2567 will cause gdb to reattach to the current thread. I commonly use 1,
2586 o With ps, get the pid of the gdb that ddd started. You can ask the
2587 gdb to tell you, but for some reason that confuses things and
2590 o run UML with 'debug=parent gdb-pid=<pid>' added to the command line
2593 o type 'att 1' to the ddd gdb and you will see something like
2599 (gdb)
2612 gdb has support for debugging code which is dynamically loaded into
2617 Using that support is somewhat complicated. You have to tell gdb what
2622 tell gdb to forget about all its symbols, including the main UML ones
2650 Start UML as: ./linux <kernel switches> debug gdb-pid=21903
2654 GNU gdb 5.0rh-5 Red Hat Linux 7.1
2661 (gdb) b sys_init_module
2663 (gdb) att 1
2674 (UML gdb) c
2703 (UML gdb) finish
2709 (UML gdb)
2713 (UML gdb) symbol-file ./linux
2717 (UML gdb)
2726 (UML gdb) p *module_list
2747 modprobe. With gdb, do:
2750 (UML gdb) p module_list
2765 (UML gdb)
2777 (UML gdb)
2783 Tell gdb you really want to do it, and you're in business.
2803 gdb to forget about the old one. The only way I've found to do that
2804 is to tell gdb to forget about all symbols that it knows about:
2807 (UML gdb) symbol-file
2815 (UML gdb) symbol-file /path/to/kernel
2822 gdb couldn't figure out where they should go.
2826 11.5. Attaching gdb to the kernel
2828 If you don't have the kernel running under gdb, you can attach gdb to
2844 you will get an xterm with gdb running in it.
2848 can be used to start gdb:
2851 (mconsole) (mconsole) config gdb=xterm
2856 will fire up an xterm with gdb running in it.
2863 than starting gdb itself. This is present in CVS as of 17 Apr 2001.
2868 This is useful when gdb is a subprocess of some UI, such as emacs or
2869 ddd. It can also be used to run debuggers other than gdb on UML.
2877 If you are using gdb under some UI, then tell it to 'att 1', and
2881 If you are using something other than gdb as your debugger, then
2897 o Run UML with 'debug' and 'gdb-pid=<pid>' with the pid printed out
3004 The standard drill in this sort of situation is to fire up gdb on the
3006 I run gdb and attach pid 1935.
3011 ~/linux/2.3.26/um 1016: gdb linux
3012 GNU gdb 4.17.0.11 with Linux support
3020 (gdb) att 1935
3033 (gdb) p current_task.pid
3048 (gdb) p current_task.prev_task.comm
3059 (gdb) p current_task.prev_task.thread
3084 before gdb can attach it:
3095 (gdb) call detach(1980)
3098 <function called from gdb>
3103 (gdb) call detach(1980)
3118 (gdb) det
3120 (gdb) att 1980
3123 (gdb) bt
3161 (gdb) p (void *)1342179328
3182 (gdb) up
3185 (gdb)
3189 (gdb)
3193 (gdb)
3196 (gdb)
3199 (gdb)
3202 (gdb)
3205 (gdb)
3208 (gdb) p *sc
3217 (gdb) p *((struct sigcontext *) (&sig + 1))
3230 (gdb) p (void *)268480945
3232 (gdb) i sym $20
3242 (gdb) i line *$20
3256 (gdb) i line *0x1000b1c0
3260 (gdb) i line *0x1000b1d0
3264 (gdb) i line *0x1000b1e0
3268 (gdb) i line *0x1000b1f0
3272 (gdb) i line *0x1000b200
3276 (gdb) i line *0x1000b210
3280 (gdb) i line *0x1000b220
3295 (gdb) call pgd_offset_proc(vma->vm_mm, address)
3306 (gdb) p *vma
3313 (gdb) p *vma.vm_mm
3336 (gdb) p vma
3359 (gdb) x/100x $25
3467 attach to it with gdb. This is done by sending it a SIGUSR1, which is
3477 Now I can run gdb on it:
3491 ~/linux/2.3.26/um 1034: gdb linux
3492 GNU gdb 4.17.0.11 with Linux support
3499 (gdb) att 4127
3512 (gdb) bt
3538 (gdb) p (void *)1342179328
3557 (gdb) up
3561 (gdb)
3564 (gdb)
3567 (gdb)
3570 (gdb) p *sc
3577 (gdb) p (void *)268550834
3579 (gdb) i sym $2
3581 (gdb) i line *$2
3585 (gdb) i line *0x1001c2c0
3623 (gdb) disas 0x1001c2bf 0x1001c2e0
3646 (gdb) p (void *)1342631484
3648 (gdb) p 0x5006ee3c+0xfffffdd4
3650 (gdb) p (void *)$6
3652 (gdb) p *((void **)$7)
3663 (gdb) p *((struct buffer_head *)0x50100200)
3689 (gdb) p *$13.b_page
3709 (gdb) p (void *)1342177280
3711 (gdb) p mem_map
3725 (gdb) p (void *)132
3769 (gdb) p bootmem_map
4085 line). An xterm will start up with gdb running inside it. Continue
4086 it when it stops in start_kernel and make it crash. Now ^C gdb and
4094 (UML gdb) backtrace
4113 (UML gdb) i sym 268849158
4121 (UML gdb) i line *268849158
4137 figuring out what its pid is, firing up gdb, and attaching it to that
4177 debugger is defunct and without some fancy footwork, another gdb can't
4188 Run gdb on the tracing thread as described in case 2 and do:
4191 (host gdb) call detach(pid)
4199 (host gdb) detach
4206 (host gdb) attach pid
4211 If gdb hangs when attaching to that process, go back to a shell and
4224 (host gdb) backtrace
4253 to it with gdb and get a backtrace as described in case 3.