Memory +Dump Commands

Using the first format you provide the start and end addresses that you +want to inspect; for example:

Using the second form you provide the start address and the number of bytes +to dump (in hex); for example:

Both of the above examples dump 64 bytes from address 0x81240000. The output +is a standard hex-dump:

Dumping the contents of classes

You can use the m command +to inspect the contents of structures and class instances, but you need to +be aware of a few things about the memory layout:

Symbian platform is +little-endian, which means that all values are stored so that the least significant +bytes are stored at the lower addresses in memory (or “backwards” as commonly +perceived).

For example, the value 0x1234ABCD would be shown in the +memory dump as:
CD AB 34 12
The compiler may add +padding between variables either to speed up access or to avoid alignment +restrictions; for example, words cannot be on odd addresses.

As an +example, the following struct:
struct SExample + { + TUint8 iByte; + TInt iInteger; + }; +
would be laid out in memory as:
+0(1) iByte ++1(3) padding ++4(4) iInteger +
The padding and alignment is compiler-dependent. Generally, +fields must be aligned on a boundary equal to their size; for example, a TUint32 is +4 bytes wide so it must lie on a 4-byte boundary, i.e. the least significant +two bits of the address must be zero.

When using GCC, classes which +derive from CBase will have a virtual table pointer as +the first word in the class data and classes which derive from DBase will +have a virtual table pointer as the second word in the class data.

When +using an EABI-compliant compiler, the virtual table pointer is always the +first word of the class.