Christopher Hallinan - Embedded Linux Primer - A Practical, Real-World Approach

122 emacdata = def->additions;

123 memcpy(emacdata->mac_addr, __res.bi_enet1addr, 6);

124 emacdata->phy_mode = PHY_MODE_RMII;

125 }

126

...

304

305 static void __init

306 yosemite_setup_arch(void)

307 {

308 yosemite_set_emacdata();

309

310 ibm440gx_get_clocks(&clocks, YOSEMITE_SYSCLK, 6 * 1843200);

311 ocp_sys_info.opb_bus_freq = clocks.opb;

312

313 /* init to some ~sane value until calibrate_delay() runs */

314 loops_per_jiffy = 50000000/HZ;

315

316 /* Setup PCI host bridge */

317 yosemite_setup_hose();

318

319 #ifdef CONFIG_BLK_DEV_INITRD

320 if (initrd_start)

321 ROOT_DEV = Root_RAM0;

322 else

323 #endif

324 #ifdef CONFIG_ROOT_NFS

325 ROOT_DEV = Root_NFS;

326 #else

327 ROOT_DEV = Root_HDA1;

328 #endif

329

330 yosemite_early_serial_map();

331

332 /* Identify the system */

333 printk("AMCC PowerPC " BOARDNAME " Platform\n");

334 }

335

To summarize the previous discussion:

• We entered a breakpoint in gdb at yosemite_setup_arch().

• When the breakpoint was hit, we found ourselves at line 116 of the source file, which was far removed from the function where we defined the breakpoint.

• We produced a disassembly listing of the code at yosemite_setup_arch() and discovered the labels to which this sequence of code was branching.

• Comparing the labels back to our source code, we discovered that the compiler had placed the yosemite_set_emacdata() subroutine inline with the function where we entered a breakpoint, causing potential confusion.

This explains the line numbers reported by gdb when the original breakpoint in yosemite_setup_arch() was hit.

Compilers employ many different kinds of optimization algorithms. This example presented but one: function inlining. Each can confuse a debugger (the human and the machine) in a different way. The challenge is to understand what is happening at the machine level and translate that into what we as developers had intended. You can see now the benefits of using the minimum possible optimization level for debugging.

You might already realize that gdb looks for an initialization file on startup, called .gdbinit. When first invoked, gdb loads this initialization file (usually found in the user's home directory) and acts on the commands within it. One of my favorite combinations is to connect to the target system and set initial breakpoints. In this case, the contents of .gdbinit would look like Listing 14-10.

Listing 14-10. Simple gdb Initialization File

$ cat ~/.gdbinit

set history save on

set history filename ~/.gdb_history

set output-radix 16

define connect

# target remote bdi:2001

target remote /dev/ttyS0

b panic

b sys_sync

end

This simple .gdbinit file enables the storing of command history in a user-specified file and sets the default output radix for printing of values. Then it defines a gdb user-defined command called connect. (User-defined commands are also often called macros.) When issued at the gdb command prompt, gdb connects to the target system via the desired method and sets the system breakpoints at panic() and sys_sync(). One method is commented out; we discuss this method shortly in Section 14.4.

There is no end to the creative use of gdb user-defined commands. When debugging in the kernel, it is often useful to examine global data structures such as task lists and memory maps. Here we present several useful gdb user-defined commands capable of displaying specific kernel data that you might need to access during your kernel debugging.

During kernel debugging, it is often useful to view the processes that are running on the system, as well as some common attributes of those processes. The kernel maintains a linked list of tasks described by struct task_struct. The address of the first task in the list is contained in the kernel global variable init_task, which represents the initial task spawned by the kernel during startup. Each task contains a struct list_head, which links the tasks in a circular linked list. These two ubiquitous kernel structures are described in the following header files:

struct task_struct .../include/linux/sched.h

struct list_head .../include/linux/list.h

Using gdb macros, we can traverse the task list and display useful information about the tasks. It is easy to modify the macros to extract the data you might be interested in. It is also a very useful tool for learning the details of kernel internals.

The first macro we examine (in Listing 14-11) is a simple one that searches the kernel's linked list of task_struct structures until it finds the given task. If it is found, it displays the name of the task.

Listing 14-11. gdb find_task Macro

1 # Helper function to find a task given a PID or the

2 # address of a task_struct.

3 # The result is set into $t

4 define find_task

5 # Addresses greater than _end: kernel data...

6 # ...user passed in an address

7 if ((unsigned)$arg0 > (unsigned)&_end)

8 set $t=(struct task_struct *)$arg0

9 else

10 # User entered a numeric PID

11 # Walk the task list to find it

12 set $t=&init_task

13 if (init_task.pid != (unsigned)$arg0)

14 find_next_task $t

15 while (&init_task!=$t && $t->pid != (unsigned)$arg0)

16 find_next_task $t

17 end

18 if ($t == &init_task)

19 printf "Couldn't find task; using init_task\n"

20 end

21 end

22 end

23 printf "Task \"%s\":\n", $t->comm

24 end

Place this text into your .gdbinit file and restart gdb, or source [95] A helpful shortcut for macro development is the gdb source command. This command opens and reads a source file containing macro definitions. it using gdb's source command. (We explain the find_next_task macro later in Listing 14-15.) Invoke it as follows:

(gdb) find_task 910

Task "syslogd":

or

(gdb) find_task 0xCFFDE470

Task "bash":

Line 4 defines the macro name. Line 7 decides whether the input argument is a PID (numeric entry starting at zero and limited to a few million) or a task_struct address that must be greater than the end of the Linux kernel image itself, defined by the symbol _end. [96] The symbol _end is defined in the linker script file during the final link. If it's an address, the only action required is to cast it to the proper type to enable dereferencing the associated task_struct. This is done at line 8. As the comment in line 3 states, this macro returns a gdb convenience variable typecasted to a pointer to a struct task_struct.