Section 13.5. Binary Utilities
13.5. Binary UtilitiesBinary utilities, or binutils, are a critical component of any toolchain. Indeed, to build a compiler, you must first have successfully built binutils. In this section, we briefly introduce the more useful tools that the embedded developer needs to know about. As with most of the other tools in this chapter, these are cross-utilities and must be built to execute on your development host while operating on binary files targeted to your chosen architecture. Alternatively, you could compile or obtain versions of these to run on your target, but we assume a cross-development environment for these examples. 13.5.1. readelfThe readelf utility examines the composition of your target ELF binary file. This is particularly useful for building images targeted for ROM or Flash memory where explicit control of the image layout is required. It is also a great tool for learning how your toolchain builds images and for understanding the ELF file format. For example, to display the symbol table in an ELF image, use this command: $ readelf -s <elf-image>To discover and display all the sections in your ELF image, use this command: $ readelf -e <elf-image>Use the -S flag to list the section headers in your ELF image. You might be surprised to learn that even a simple seven-line "hello world" program contains 38 separate sections. Some of them will be familiar to you, such as the .text and .data sections. Listing 13-15 contains a partial listing of sections from our "hello world" example. For simplicity, we have listed only those sections that are likely to be familiar or relevant to the embedded developer. Listing 13-15. readelf Section Headers
The .text section contains the executable program code. The .rodata section contains constant data in your program. The .data section generally contains initialized global data used by the C library prologue code and can contain large initialized data items from your application. The .sdata section is used for smaller initialized global data items and exists only on some architectures. Some processor architectures can make use of optimized data access when the attributes of the memory area are known. The .sdata and .sbss sections enable these optimizations. The .bss and .sbss sections contain uninitialized data in your program. These sections occupy no space in the program imagetheir memory space is allocated and initialized to zero on program startup by C library prologue code. We can dump any of these sections and display the contents. Given this line in your C program declared outside of any function, we can examine how it is placed in the .rodata section: char *hello_rodata = "This is a read-only data string\n"; Issue the readelf command specifying the section number we want to dump from Listing 13-15: $ ppc_82xx-readelf -x 13 hello-ex Hex dump of section '.rodata': 0x10000878 100189e0 10000488 1000050c 1000058c ................ 0x10000888 00020001 54686973 20697320 61207265 ....This is a read- 0x10000898 61642d6f 6e6c7920 64617461 20737472 only data string 0x100008a8 696e670a 00000000 54686973 20697320 .....This is 0x100008b8 73746174 69632064 6174610a 00000000 static data..... 0x100008c8 48656c6c 6f20456d 62656464 65640a00 Hello Embedded.. 0x100008d8 25730a00 25780a00 %s..%x..We see that the initialized global variable that we declared is represented in the .rodata section, together with all the constant strings defined in the program. 13.5.2. Examining Debug Info Using readelfOne of the more useful features of readelf is to display the debug information contained in an ELF file. When the -g compiler flag is issued during a compilation, the compiler generates debug information in a series of sections within the resulting ELF file. We can use readelf to display these ELF section headers within the ELF file: $ ppc-linux-readelf -S ex_sync | grep debug [28] .debug_aranges PROGBITS 00000000 000c38 0000b8 00 0 0 8 [29] .debug_pubnames PROGBITS 00000000 000cf0 00007a 00 0 0 1 [30] .debug_info PROGBITS 00000000 000d6a 00079b 00 0 0 1 [31] .debug_abbrev PROGBITS 00000000 001505 000207 00 0 0 1 [32] .debug_line PROGBITS 00000000 00170c 000354 00 0 0 1 [33] .debug_frame PROGBITS 00000000 001a60 000080 00 0 0 4 [34] .debug_str PROGBITS 00000000 001ae0 00014d 00 0 0 1Using readelf with the --debug-dump option, we can display the contents of any one of these .debug_* sections. You will see how this information can be useful in Chapter 14, "Kernel Debugging Techniques," when we discuss the challenge of debugging optimized kernel code. Debug information can be very large. Displaying all the debug information in the Linux kernel ELF file vmlinux produces more than six million lines of output. However daunting it might appear, having at least a familiarity with debug information will make you a better embedded engineer. Listing 13-16 is a partial listing of the contents of the .debug_info section from a small example application. For space considerations, we have shown only a few records. Listing 13-16. Partial Debug Info Dump
The first record identified by the Dwarf2[8] 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. 13.5.3. objdumpThe 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
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. objcopyobjcopy 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[9] 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.binThis objcopy invocation shows how an image might be prepared for Flash memory. The input fileu-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. |
EAN: 2147483647
Pages: 167