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

404 DW_AT_frame_base : 1 byte block: 6f (DW_OP_reg31)

...

423 <2><5e9>: Abbrev Number: 16 (DW_TAG_variable)

424 DW_AT_name : mybuf

425 DW_AT_decl_file : 1

426 DW_AT_decl_line : 11

427 DW_AT_type : <600>

428 DW_AT_location : 2 byte block: 91 20 (DW_OP_fbreg: 32)

...

The first record identified by the Dwarf2 [87] A reference for the Dwarf2 Debug Information Specification is provided at the end of this chapter. tag DW_TAG_compile_unit identifies the first compilation unit of this PowerPC executable. It is a file called start.S, which provides startup prologue for a C program. The next record identified by DW_TAG_subprogram identifies the start of the user program, the familiar function main(). This Dwarf2 debug record contains a reference to the file and line number where main() is found. The final record in Listing 13-16 identifies a local variable in the main() routine called mybuf. Again, the line number and file are provided by this record. You can deduce from this information that main() is at line 9, and mybuf is at line 11 of the source file. Other debug records in the ELF file correlate the filename via the Dwarf2 DW_AT_decl_file attribute.

You can discover all the details of the Dwarf2 debug information format via the reference given in Section 13.7.1 at the end of this chapter.

The objdump utility has considerable overlap with the readelf tool. However, one of the more useful features of objdump is its capability to display disassembled object code. Listing 13-17 provides an example of disassembly of the .text section of the simple "hello world" PowerPC version. We include only the main() routine, to save space. The entire dump, including C library prologue and epilogue, would consume many pages.

Listing 13-17. Disassembly Using objdump

$ ppc_82xx-objdump -S -m powerpc:common -j .text hello

...

10000488

10000488: 94 21 ff e0 stwu r1,-32(r1)

1000048c: 7c 08 02 a6 mflr r0

10000490: 93 e1 00 1c stw r31,28(r1)

10000494: 90 01 00 24 stw r0,36(r1)

10000498: 7c 3f 0b 78 mr r31,r1

1000049c: 90 7f 00 08 stw r3,8(r31)

100004a0: 90 9f 00 0c stw r4,12(r31)

100004a4: 3d 20 10 00 lis r9,4096

100004a8: 38 69 08 54 addi r3,r9,2132

100004ac: 4c c6 31 82 crclr 4*cr1+eq

100004b0: 48 01 05 11 bl 100109c0

<__bss_start+0x60>

100004b4: 38 00 00 00 li r0,0

100004b8: 7c 03 03 78 mr r3,r0

100004bc: 81 61 00 00 lwz r11,0(r1)

100004c0: 80 0b 00 04 lwz r0,4(r11)

100004c4: 7c 08 03 a6 mtlr r0

100004c8: 83 eb ff fc lwz r31,-4(r11)

100004cc: 7d 61 5b 78 mr r1,r11

100004d0: 4e 80 00 20 blr

...

Much of the code from the simple main() routine is stack frame creation and destruction. The actual call to printf() is represented by the branch link (bl) instruction near the center of the listing at address 0x100004b0. This is a PowerPC function call. Because this program was compiled as a dynamically linked object, we will not have an address for the printf() function until runtime, when it is linked with the shared library printf() routine. Had we compiled this as a statically linked object, we would see the symbol and corresponding address for the call to printf().

objcopy formats and, optionally, converts the format of a binary object file. This utility is quite useful for generating code for ROM or Flash resident images. The U-Boot bootloader introduced in Chapter 7 makes use of objcopy to produce binary and s-record [88] S-record files are an ASCII representation of a binary file, used by many device programmers and software binary utilities. output formats from the final ELF file. This example usage illustrates the capabilities of objcopy and its use to build Flash images.

$ ppc_82xx-objcopy --gap-fill=0xff -O binary u-boot u-boot.bin

This objcopy invocation shows how an image might be prepared for Flash memory. The input file u-boot, in this exampleis the complete ELF U-Boot image, including symbols and relocation information. The objcopy utility takes only the relevant sections containing program code and data and places the image in the output file, specified here as u-boot.bin.

Flash memory contains all ones in its erased state. Therefore, filling gaps in a binary image with all ones improves programming efficiency and prolongs the life of the Flash memory, which today has limited write cycles. This is done with the --gap-fill parameter to objcopy.

This is but one simple example usage of objcopy. This utility can be used to generate s-records and convert from one format to another. See the man page for complete details.

Your toolchain contains several additional useful utilities. Learning to use these utilities is straightforward. You will find many uses for these helpful tools.

The strip utility can be used to remove symbols and debug information from a binary. This is frequently used to save space on an embedded device. In the cross-development model, it is convenient to place stripped binaries on the target system and leave the unstripped version on your development host. Using this method, symbols are available for cross-debugging on your development host while saving space on the target. strip has many options, which are described in the man page.

When we highlighted mtrace in Listing 13-12, you saw that the output from the mtrace analysis script contained file and line number information. The mTRace Perl script used the addr2line utility to read the debug information contained in the executable ELF file and display a line number corresponding to the address. Using the same mtrace example executable, we can find a filename and line number for a virtual address:

$ addr2line -f -e mt_ex 0x80487c6

put_data

/home/chris/examples/mt_ex.c:64

Notice that the function put_data() is also listed together with the file and line number. This says that the address 0x80487c6 is on line 64 of the mt_ex.c file, in the put_data() function. This is even more useful in larger binaries consisting of multiple filenames, such as the Linux kernel:

$ ppc_82xx-addr2line -f -e vmlinux c000d95c

mpc52xx_restart

arch/ppc/syslib/mpc52xx_setup.c:41

This particular example highlights one of the points repeated throughout this chapter: This is an architecture-specific tool. You must use a tool configured and compiled to match the architecture of the target binary that you are using. As with the cross-compiler, addr2line is a cross-tool and part of the binary utilities package.