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

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

The 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

To discover and display all the sections in your ELF image, use this command:

$ readelf -e

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

$ ppc_82xx-readelf -S hello-ex

There are 38 section headers, starting at offset 0x32f4:

Section Headers:

[ Nr] Name Type Addr Off Size ES Flg Lk Inf Al

...

[11] .text PROGBITS 100002f0 0002f0 000568 00 AX 0 0 4

...

[13] .rodata PROGBITS 10000878 000878 000068 00 A 0 0 4

...

[15] .data PROGBITS 100108e0 0008e0 00000c 00 WA 0 0 4

...

[22] .sdata PROGBITS 100109e0 0009e0 00001c 00 WA 0 0 4

[23] .sbss NOBITS 100109fc 0009fc 000000 00 WA 0 0 1

...

[25] .bss NOBITS 10010a74 0009fc 00001c 00 WA 0 0 4

...

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.

One 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 1

Using 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

$ ppc-linux-readelf -debug-dump=info ex_sync

1 The section .debug_info contains:

2

3 Compilation Unit @ 0:

4 Length: 109

5 Version: 2

6 Abbrev Offset: 0

7 Pointer Size: 4

8 <0>: Abbrev Number: 1 (DW_TAG_compile_unit)

9 DW_AT_stmt_list : 0

10 DW_AT_low_pc : 0x10000368

11 DW_AT_high_pc : 0x1000038c

12 DW_AT_name :

../sysdeps/powerpc/powerpc32/elf/start.S

13 DW_AT_comp_dir : /var/tmp/BUILD/glibc-2.3.3/csu

14 DW_AT_producer : GNU AS 2.15.94

15 DW_AT_language : 32769 (MIPS assembler)

...

394 <1><5a1>: Abbrev Number: 14 (DW_TAG_subprogram)

395 DW_AT_sibling : <5fa>

396 DW_AT_external : 1

397 DW_AT_name : main

398 DW_AT_decl_file : 1

399 DW_AT_decl_line : 9

400 DW_AT_prototyped : 1

401 DW_AT_type : <248>

402 DW_AT_low_pc : 0x100004b8

403 DW_AT_high_pc : 0x10000570