13.5.3. objdump

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 <main>:

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().

13.5.4. objcopy

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] 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.

13.6. Miscellaneous Binary Utilities

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

13.6.1. strip

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.

13.6.2. addr2line

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

Добавить отзыв
ВСЕ ОТЗЫВЫ О КНИГЕ В ИЗБРАННОЕ

0

Вы можете отметить интересные вам фрагменты текста, которые будут доступны по уникальной ссылке в адресной строке браузера.

Отметить Добавить цитату