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

Breakpoint 3 at 0xc020f438: file arch/ppc/platforms/4xx/yosemite.c, line 116.

(gdb) c

Continuing.

Breakpoint 3, yosemite_setup_arch ()

at arch/ppc/platforms/4xx/yosemite.c:116

116 def = ocp_get_one_device(OCP_VENDOR_IBM, OCP_FUNC_EMAC, 0);

(gdb) l

111 struct ocp_def *def;

112 struct ocp_func_emac_data *emacdata;

113

114 /* Set mac_addr and phy mode for each EMAC */

115

116 def = ocp_get_one_device(OCP_VENDOR_IBM, OCP_FUNC_EMAC, 0);

117 emacdata = def->additions;

118 memcpy(emacdata->mac_addr, __res.bi_enetaddr, 6);

119 emacdata->phy_mode = PHY_MODE_RMII;

120

(gdb) p yosemite_setup_arch

$1 = {void (void)} 0xc020f41c

Referring back to Listing 14-4, notice that the function yosemite_setup_arch() actually falls on line 306 of the file yosemite.c. Compare that with Listing 14-7. We hit the breakpoint, but gdb reports the breakpoint at file yosemite.c line 116. It appears at first glance to be a mismatch of line numbers between the debugger and the corresponding source code. Is this a gdb bug? First let's confirm what the compiler produced for debug information. Using the readelf [93] Remember to use your cross-version of readelffor example, ppc_44x-readelf for the PowerPC 44x architecture. tool described in Chapter 13, "Development Tools," we can examine the debug information for this function produced by the compiler.

$ ppc_44x-readelf --debug-dump=info vmlinux | grep -u6 yosemite_setup_arch | tail -n 7

DW_AT_name : (indirect string, offset: 0x9c04): yosemite_setup_arch

DW_AT_decl_file : 1

DW_AT_decl_line : 307

DW_AT_prototyped : 1

DW_AT_low_pc : 0xc020f41c

DW_AT_high_pc : 0xc020f794

DW_AT_frame_base : 1 byte block: 51 (DW_OP_reg1)

We don't have to be experts at reading DWARF2 debug records [94] A reference for the Dwarf debug specification appears at the end of this chapter in Section 14.6.1, "Suggestions for Additional Reading." to recognize that the function in question is reported at line 307 in our source file. We can confirm this using the addr2line utility, also introduced in Chapter 13. Using the address derived from gdb in Listing 14-7:

$ ppc_44x-addr2line -e vmlinux 0xc020f41c

arch/ppc/platforms/4xx/yosemite.c:307

At this point, gdb is reporting our breakpoint at line 116 of the yosemite.c file. To understand what is happening, we need to look at the assembler output of the function as reported by gdb. Listing 14-8 is the output from gdb after issuing the disassemble command on the yosemite_setup_arch() function.

Listing 14-8. Disassemble Function yosemite_setup_arch

(gdb) disassemble yosemite_setup_arch

0xc020f41c : mflr r0

0xc020f420 : stwu r1,-48(r1)

0xc020f424 : li r4,512

0xc020f428 : li r5,0

0xc020f42c : li r3,4116

0xc020f430 : stmw r25,20(r1)

0xc020f434 : stw r0,52(r1)

0xc020f438 : bl 0xc000d344

0xc020f43c : lwz r31,32(r3)

0xc020f440 : lis r4,-16350

0xc020f444 : li r28,2

0xc020f448 : addi r4,r4,21460

0xc020f44c : li r5,6

0xc020f450 : lis r29,-16350

0xc020f454 : addi r3,r31,48

0xc020f458 : lis r25,-16350

0xc020f45c : bl 0xc000c708

0xc020f460 : stw r28,44(r31)

0xc020f464 : li r4,512

0xc020f468 : li r5,1

0xc020f46c : li r3,4116

0xc020f470 : addi r26,r25,15104

0xc020f474 : bl 0xc000d344

0xc020f478 : lis r4,-16350

0xc020f47c : lwz r31,32(r3)

0xc020f480 : addi r4,r4,21534

0xc020f484 : li r5,6

0xc020f488 : addi r3,r31,48

0xc020f48c : bl 0xc000c708

0xc020f490 : lis r4,1017

0xc020f494 : lis r5,168

0xc020f498 : stw r28,44(r31)

0xc020f49c : ori r4,r4,16554

0xc020f4a0 : ori r5,r5,49152

0xc020f4a4 : addi r3,r29,-15380

0xc020f4a8 : addi r29,r29,-15380

0xc020f4ac : bl 0xc020e338

0xc020f4b0 : li r0,0

0xc020f4b4 : lis r11,-16352

0xc020f4b8 : ori r0,r0,50000

0xc020f4bc : lwz r10,12(r29)

0xc020f4c0 : lis r9,-16352

0xc020f4c4 : stw r0,8068(r11)

0xc020f4c8 : lwz r0,84(r26)

0xc020f4cc : stw r10,8136(r9)

0xc020f4d0 : mtctr r0

0xc020f4d4 : bctrl

0xc020f4d8 : li r5,64

0xc020f4dc : mr r31,r3

0xc020f4e0 : lis r4,-4288

0xc020f4e4 : li r3,0

0xc020f4e8 : bl 0xc000c0f8

End of assembler dump.

(gdb)

Once again, we need not be PowerPC assembly language experts to understand what is happening here. Notice the labels associated with the PowerPC bl instruction. This is a function call in PowerPC mnemonics. The symbolic function labels are the important data points. After a cursory analysis, we see several function calls near the start of this assembler listing:

Listing 14-9 reproduces portions of the source file yosemite.c. Correlating the functions we found in the gdb disassemble output, we see those labels occurring in the function yosemite_set_emacdata(), around the line numbers reported by gdb when the breakpoint at yosemite_setup_arch() was encountered. The key to understanding the anomaly is to notice the subroutine call at the very start of yosemite_setup_arch(). The compiler has inlined the call to yosemite_set_emacdata() instead of generating a function call, as would be expected by simple inspection of the source code. This inlining produced the mismatch in the line numbers when gdb hit the breakpoint. Even though the yosemite_set_emacdata() function was not declared using the inline keyword, GCC inlined the function as a performance optimization.

Listing 14-9. Portions of Source File yosemite.c

109 static void __init yosemite_set_emacdata(void)

110 {

111 struct ocp_def *def;

112 struct ocp_func_emac_data *emacdata;

113

114 /* Set mac_addr and phy mode for each EMAC */

115

116 def = ocp_get_one_device(OCP_VENDOR_IBM, OCP_FUNC_EMAC, 0);

117 emacdata = def->additions;

118 memcpy(emacdata->mac_addr, __res.bi_enetaddr, 6);

119 emacdata->phy_mode = PHY_MODE_RMII;

120

121 def = ocp_get_one_device(OCP_VENDOR_IBM, OCP_FUNC_EMAC, 1);