info:c_memory_structure
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
info:c_memory_structure [2012/10/15 05:38] – [Example program] objdump moritz | info:c_memory_structure [2012/10/15 17:09] – [Goals] moritz | ||
---|---|---|---|
Line 1: | Line 1: | ||
====== Determining C memory layout ====== | ====== Determining C memory layout ====== | ||
- | A while ago I had to write a Python program that generated C structures as C expects to find them in memory. The challenge was that the target system had a different alignment, endianness and word size than the computer running the Python scripts on. In this article I am referring to Python but the result can be transferred to any other programming language. | + | A while ago I had to write a Python program that generated C structures as C expects to find them in memory. The challenge was that the target system had a different alignment, endianness and word size than the computer running the Python scripts on. This is especially important when developing for multiple targets, like i386 and AMD64, different ARM platforms and MIPS. In this article I am referring to Python but the result can be transferred to any other programming language. |
===== Goals ===== | ===== Goals ===== | ||
Line 17: | Line 17: | ||
</ | </ | ||
- | On 32-bit machines, it is assumed that an < | + | On 32-bit machines, it is assumed that an '' |
On the Python side I want to be able to use the following code: | On the Python side I want to be able to use the following code: | ||
Line 241: | Line 241: | ||
< | < | ||
</ | </ | ||
+ | |||
+ | This is a lot of output. Let's explain the different parts. | ||
+ | |||
+ | Fist, it tells us what format the file has. In this case it is a '' | ||
+ | |||
+ | Next, it shows the contents of the debug info section. There can be different compilation units, here it is just one. It tells us that pointers indeed have a length of 8 bits. The total length of the debug info section is 0x12c. | ||
+ | |||
+ | The first compilation unit is marked with ''< | ||
+ | |||
+ | The first children of the compile unit are '' | ||
+ | |||
+ | Skipping to address 0x79 it gets more interesting: | ||
+ | < | ||
+ | It shows that our structure occupies 8 bytes in memory, which we can verify using the output of our sample program. Nested under the structure type, we find several '' | ||
+ | |||
+ | < | ||
+ | Here, '' | ||
+ | |||
+ | ==== Using the debug info dump ==== | ||
+ | |||
+ | The output of the debug info dump can be read again by a program in order to extract the '' | ||
+ | |||
+ | ==== Problems ==== | ||
+ | |||
+ | This approach has the downside that it requires a certain format of the debug dump. Also, it does not specify the endianness of the types. | ||
+ | |||
+ | ===== IAR ===== | ||
+ | |||
+ | The same can be done with the tools that come with the IAR C/C++ compiler. The ELF dump utility is called '' | ||
+ | |||
+ | |||
+ |
info/c_memory_structure.txt · Last modified: 2012/10/16 17:23 by moritz