"Linux Device Drivers" The fourth chapter debugging technology--note

1. Knowledge points in this chapter

• Kernel and debug-related options
  • Config_debug_kernel
  • Config_debug_slab
  • Config_debug_pagealloc
  • Config_debug_spinlock
  • Config_debug_spinlock_sleep
  • Config_init_debug
  • Config_debug_info
  • Config_magic_sysrq
  • Config_debug_stackoverflow
  • Config_debug_stack_usage
  • Config_kallsyms
  • Config_ikconfig
  • Config_ikconfig_proc
  • Config_acpi_debug
  • Config_debug_driver
  • Config_scsi_constants
  • Config_input_evbug
  • Config_profiling

• Debug with Print
  • Printk
    • Allows PRINTK to categorize messages by attaching different log levels
    • <linux/kernel.h>
      • Kern_emerg
      • Kern_alert
      • Kern_crit
      • Kern_err
      • Kern_warning
      • Kern_notice
      • Kern_info
      • Kern_debug
    • The default level is Default_message_loglevel
      • 2.6.10 kernel, the default level is Kern_warning
    • /proc/sys/kernel/printk
      • 4 integer values
      • The current log level, the default message level when the log level is not explicitly specified, the minimum allowable log level, and the default log level at boot time
  • Redirecting console messages
  • How messages are recorded
    • The PRINTK function writes the message to a circular buffer of length __log_buf_len bytes
    • Wakes a process that is waiting for a message, or is reading a/proc/kmsg process
    • PRINTK can be called anywhere, even in interrupt handling functions, and there is no limit to the size of the data volume
    • Klogd
    • Syslogd
    • /etc/syslog.conf
  • Open and close messages
    • Defines a macro that, when needed, expands to a PRINTK (printf) call
      • You can enable or disable each print statement by deleting or adding a letter to the macro name
      • Modify the Cflags variable before compiling, you can disable all messages at once
      • The same print statement can be used in the kernel code or in user-level code
  • Speed limit
    • /proc/sys/kernel/printk_ratelimit
    • /proc/sys/kernel/printk_ratelimit_burst
  • Print device number
    • <linux/kdev_t.h>
      • int print_dev_t (char *buffer, dev_t Dev);
      • Char *format_dev_t (char *buffer, dev_t Dev);
• Debug with Query
  • Syslogd
    • Try to log everything to disk, so that when the system crashes, the last recorded information responds to the situation before the crash.
  • The system can be queried using the following methods
    • Creating files in the/proc file system, using the driver's IOCTL method, and exporting properties through SYSFS, etc.
  • Using the/proc file system
    • The/proc file system is a special, software-created file system that the kernel uses to export information to the outside world.
    • /proc each of the following files is bound to a kernel function where the user's file is dynamically generated by the "content" of the file
    • Implementing Files in/proc
      • <linux/proc_fs.h>
      • Implement a function to create a read-only/proc file
        • Int (*read_proc) (Char *page, char **start, off_t offset, int count, int *eof, void *data);
        • The EOF parameter must be set when no data can be returned.
        • A simple Read_proc method that returns a small amount of data ignores the start parameter, and the complex Read_proc method sets the *start to the page and places the data at the requested offset into the memory page
        • Seq_file
    • To create your own/proc file
      • It needs to be connected to a/PROC entry.
      • struct Proc_dir_entry *create_proc_read_entry (const char *name, mode_t mode, struct proc_dir_entry *base, read_proc_t *re Ad_proc, void *data);
      • Remove_proc_entry (const char *name, struct proc_dir_entry *base);
      • There is a regular agreement that requires that the device driver corresponding to the/PROC entry be transferred to the subdirectory driver/
      • Entry entries in the/proc should also be deleted when the module is unloaded
      • Use of/proc files is discouraged
  • Seq_file interface
    • Create a simple Iterator object
    • <linux/seq_file.h>
    • Create four iterator objects: Start, Next, stop, show
      • void *start (struct seq_file *sfile, loff_t *pos);
      • void *next (struct seq_file *sfile, void *v, loff_t *pos);
      • void Stop (struct seq_file *sfile, void *v);
      • int show (struct seq_file *sfile, void *v);
        • int seq_printf (struct seqfile *sfile, const char *fmt, ...);
        • int SEQ_PUTC (struct seqfile *sfile, char c);
        • int seq_puts (struct seqfile *sfile, const char *s);
        • int Seq_escape (struct seqfile *m, const char *s, const char *ESC);
        • int Seq_path (struct seq_file *sfile, struct vfsmount *m, struct dentry *dentry, char *esc);
    • static struct seq_operations seq_ops ={.start=start,. Next=next,. stop=stop,. Show=show};
    • static int Proc_open (struct inode *inode, struct file *file) {return Seq_open (file, &seq_ops);}
    • static struct File_operations Proc_ops = {. Owner=this_module,. Open=proc_open,. Read=seq_read,. Llseek=seq_lseek,. Release=seq_release};
    • Entry = Create_proc_entry ("seq", 0, NULL);
    • Entry->proc_fops = &proc_ops;
    • struct Proc_dir_entry *create_proc_entry (const char *name, mode_t mode, struct proc_dir_entry *parent);
  • Ioctl method
    • Receive a "command" number and another (optional) parameter
• Debugging by monitoring
  • The Strace command is a very powerful tool that can display all system calls made by a user-space program
    • -T: Used to show when the call occurred
    • -T: Show the time taken by the call
    • -E: Limit the type of calls being traced
    • -o: Redirect output to a file
    • By default, strace prints trace information to stderr
    • Strace can also track a running process
• Debug system failure
  • Oops message
    • Because the null pointer is being evaluated or other incorrect pointer values are used
  • System hangs
    • SYSRQ Magic Key
      • Alt+rsyrq
      • /proc/sys/kernel/sysrq
      • /proc/sysrq-trigger
• Debuggers and related tools
  • Using GDB
    • Gdb/usr/src/linux/vmlinux/proc/kcore
      • The first parameter is the name of the uncompressed kernel elf executable file
      • The second parameter is the name of the core file
    • In order for GDB to use the kernel's symbolic information, we must compile the kernel with the Config_debug_info option turned on
    • For a debugging session, the module-related code snippet has only the following three
      • . Text: Contains the executable code for the module
      • . BSS,. Data: These two code snippets save the variables of the module, and the uninitialized variables at compile time are saved in the. BSS segment, which is initialized to be saved in the. Data segment
    • Code Snippet Address:/sys/module/<module name>/sections/.*
    • (gdb) Add-symbol-file Hello.ko 0xe0a27000-s. BSS 0xe0a28d00-s. Data 0xe0a279e0
  • KDB Kernel Debugger
    • Patching, oss.sgi.com download
    • Pressing the pause (or bread) key on the console will start debugging
  • Kgdb Patch
    • Isolate the system running the debug kernel from the system running the debugger and the tool, which connects between the two systems via a string line
    • Two separate patches
      • The first kgdb patch can be found in the-mm kernel tree
      • You can also use the patches on the http://kgdb.sf.net/
  • User-mode Linux virtual machines
  • Linux Tracking Toolkit
    • LLT (Linux Trace Toolkit) is a kernel patch that contains a set of related toolsets that can be used for kernel event tracking
    • Http://www.opersys.com/LTT
  • Dynamic detection
    • Dprobes (Dynamic probes) is a debugging tool that IBM publishes for IA-32 architecture-based Linux
    • http://dprobes.sourceforge.net/

2. Common Disassembly technology 2.1oops error location
(1) A vmlinux is generated at the same time when the kernel is compiled, using GDB.
When the kernel is configured, make menuconfig to open the Complie with debug Info option.
Note This line: PC is at Skb_release_data+0x74/0xc4
This tells us that the Skb_release_data function has 0xc4 so large, and oops occurs at 0x74 place. So let's take a look at where the Skb_release_data starts:
#grep Skb_release_data./system.map
C0282AF4 T Skb_release_data
So we know that when the system error occurs, the program pointer is c0282af4+0x74=c0282b68
(2) Then use GDB to view the GDB./vmlinux (executed under the Linux directory) and enter debug mode.
gdb$ b *0xc0282b68
Breakpoint 1 at 0xc0282b68:file NET/CORE/SKBUFF.C, line312
This is to tell us in which file, in which line. So know the wrong position, the specific reason to solve.
(2) Disassembly
gdb$ disassemble 0xc0282b68


2.2 Decompile a row
First Readelf-a Vmlinux | grep Setup_arch Get the relevant information:
12707:c0351020 543 FUNC GLOBAL DEFAULT 9 Setup_arch
Where c0351020 is the starting address and 543 is the length (10 binary),
Then use objdump-d--start-address=0xc0351020--stop-address=0xc035123f vmlinux


2.3 Disassembly a file execute commands under the kernel directory $make Help | grep LST will have dir/file.lst-build specified mixed source/assembly target only
(Requires a recent binutils and recent build (SYSTEM.MAP)) that is make xxx.lst to disassemble a file

"Linux Device Drivers" The fourth chapter debugging technology--note