.. | .. |
---|
274 | 274 | on the initial connect, or to use a debugger proxy that allows an |
---|
275 | 275 | unmodified gdb to do the debugging. |
---|
276 | 276 | |
---|
| 277 | +Kernel parameter: ``kgdboc_earlycon`` |
---|
| 278 | +------------------------------------- |
---|
| 279 | + |
---|
| 280 | +If you specify the kernel parameter ``kgdboc_earlycon`` and your serial |
---|
| 281 | +driver registers a boot console that supports polling (doesn't need |
---|
| 282 | +interrupts and implements a nonblocking read() function) kgdb will attempt |
---|
| 283 | +to work using the boot console until it can transition to the regular |
---|
| 284 | +tty driver specified by the ``kgdboc`` parameter. |
---|
| 285 | + |
---|
| 286 | +Normally there is only one boot console (especially that implements the |
---|
| 287 | +read() function) so just adding ``kgdboc_earlycon`` on its own is |
---|
| 288 | +sufficient to make this work. If you have more than one boot console you |
---|
| 289 | +can add the boot console's name to differentiate. Note that names that |
---|
| 290 | +are registered through the boot console layer and the tty layer are not |
---|
| 291 | +the same for the same port. |
---|
| 292 | + |
---|
| 293 | +For instance, on one board to be explicit you might do:: |
---|
| 294 | + |
---|
| 295 | + kgdboc_earlycon=qcom_geni kgdboc=ttyMSM0 |
---|
| 296 | + |
---|
| 297 | +If the only boot console on the device was "qcom_geni", you could simplify:: |
---|
| 298 | + |
---|
| 299 | + kgdboc_earlycon kgdboc=ttyMSM0 |
---|
| 300 | + |
---|
277 | 301 | Kernel parameter: ``kgdbwait`` |
---|
278 | 302 | ------------------------------ |
---|
279 | 303 | |
---|
.. | .. |
---|
292 | 316 | Kernel parameter: ``kgdbcon`` |
---|
293 | 317 | ----------------------------- |
---|
294 | 318 | |
---|
295 | | -The ``kgdbcon`` feature allows you to see :c:func:`printk` messages inside gdb |
---|
| 319 | +The ``kgdbcon`` feature allows you to see printk() messages inside gdb |
---|
296 | 320 | while gdb is connected to the kernel. Kdb does not make use of the kgdbcon |
---|
297 | 321 | feature. |
---|
298 | 322 | |
---|
.. | .. |
---|
408 | 432 | ``ps`` Displays only the active processes |
---|
409 | 433 | ``ps A`` Shows all the processes |
---|
410 | 434 | ``summary`` Shows kernel version info and memory usage |
---|
411 | | - ``bt`` Get a backtrace of the current process using :c:func:`dump_stack` |
---|
| 435 | + ``bt`` Get a backtrace of the current process using dump_stack() |
---|
412 | 436 | ``dmesg`` View the kernel syslog buffer |
---|
413 | 437 | ``go`` Continue the system |
---|
414 | 438 | =========== ================================================================= |
---|
.. | .. |
---|
700 | 724 | The arch-specific portion implements: |
---|
701 | 725 | |
---|
702 | 726 | - contains an arch-specific trap catcher which invokes |
---|
703 | | - :c:func:`kgdb_handle_exception` to start kgdb about doing its work |
---|
| 727 | + kgdb_handle_exception() to start kgdb about doing its work |
---|
704 | 728 | |
---|
705 | | - - translation to and from gdb specific packet format to :c:type:`pt_regs` |
---|
| 729 | + - translation to and from gdb specific packet format to struct pt_regs |
---|
706 | 730 | |
---|
707 | 731 | - Registration and unregistration of architecture specific trap |
---|
708 | 732 | hooks |
---|
.. | .. |
---|
745 | 769 | config. Later run ``modprobe kdb_hello`` and the next time you |
---|
746 | 770 | enter the kdb shell, you can run the ``hello`` command. |
---|
747 | 771 | |
---|
748 | | - - The implementation for :c:func:`kdb_printf` which emits messages directly |
---|
| 772 | + - The implementation for kdb_printf() which emits messages directly |
---|
749 | 773 | to I/O drivers, bypassing the kernel log. |
---|
750 | 774 | |
---|
751 | 775 | - SW / HW breakpoint management for the kdb shell |
---|
.. | .. |
---|
822 | 846 | the UART driver. |
---|
823 | 847 | |
---|
824 | 848 | When using kgdboc with a UART, the UART driver must implement two |
---|
825 | | -callbacks in the :c:type:`struct uart_ops <uart_ops>`. |
---|
| 849 | +callbacks in the struct uart_ops. |
---|
826 | 850 | Example from ``drivers/8250.c``:: |
---|
827 | 851 | |
---|
828 | 852 | |
---|
.. | .. |
---|
848 | 872 | attached keyboard. The keyboard infrastructure is only compiled into the |
---|
849 | 873 | kernel when ``CONFIG_KDB_KEYBOARD=y`` is set in the kernel configuration. |
---|
850 | 874 | |
---|
851 | | -The core polled keyboard driver driver for PS/2 type keyboards is in |
---|
| 875 | +The core polled keyboard driver for PS/2 type keyboards is in |
---|
852 | 876 | ``drivers/char/kdb_keyboard.c``. This driver is hooked into the debug core |
---|
853 | 877 | when kgdboc populates the callback in the array called |
---|
854 | | -:c:type:`kdb_poll_funcs[]`. The :c:func:`kdb_get_kbd_char` is the top-level |
---|
| 878 | +:c:expr:`kdb_poll_funcs[]`. The kdb_get_kbd_char() is the top-level |
---|
855 | 879 | function which polls hardware for single character input. |
---|
856 | 880 | |
---|
857 | 881 | kgdboc and kms |
---|
.. | .. |
---|
863 | 887 | kernel mode setting support. |
---|
864 | 888 | |
---|
865 | 889 | Every time the kernel debugger is entered it calls |
---|
866 | | -:c:func:`kgdboc_pre_exp_handler` which in turn calls :c:func:`con_debug_enter` |
---|
| 890 | +kgdboc_pre_exp_handler() which in turn calls con_debug_enter() |
---|
867 | 891 | in the virtual console layer. On resuming kernel execution, the kernel |
---|
868 | | -debugger calls :c:func:`kgdboc_post_exp_handler` which in turn calls |
---|
869 | | -:c:func:`con_debug_leave`. |
---|
| 892 | +debugger calls kgdboc_post_exp_handler() which in turn calls |
---|
| 893 | +con_debug_leave(). |
---|
870 | 894 | |
---|
871 | 895 | Any video driver that wants to be compatible with the kernel debugger |
---|
872 | 896 | and the atomic kms callbacks must implement the ``mode_set_base_atomic``, |
---|