embedded linux: first offset in /proc/pid/maps wrong?

Question

Details of my endeavour below, they are only partly relevant to my question:

In a map from /proc/pid/maps on an embedded linux (arm) with kernel version 2.6.37.6, the offset of the first line (the code segment of the executable itself) seems to be wrong.

I always see a line like:

00008000-00061000 r-xp 00000000 00:10 8073509 myprog

(the range is the address in the processes address space, the number after the permissions is supposed to be the offset into the file)

However, the actual offset seems to be 0x8000 - at least, interpretations using this assumption look much more credible. nm shows me that myprog doesn't have code before 0x8000, so that would make sense too.

Could someone give me a pointer to where I can find out more about this? I could not find anything.

What I am doing: I have written a tool to interpret logs generated by mtrace(), find possible memory leaks, and trace them back to the code allocating the data. For the latter step, I take an instruction pointer from the log, look it up in the run-time map from /proc/pid/maps to find the executable or library in question, and use their nm-map to find the actual function doing the allocation.

This works like a charm for everything but the executable itself.

Answer 1

Each row in /proc/$PID/maps describes a region of contiguous virtual memory in a process or thread. Each row has the following fields:

address           perms offset  dev   inode   pathname
08048000-08056000 r-xp 00000000 03:0c 64593   /usr/sbin/gpm

• address - This is the starting and ending address of the region in the process's address space
• permissions - This describes how pages in the region can be accessed. There are four different permissions: read, write, execute, and shared. If read/write/execute are disabled, a '-' will appear instead of the 'r'/'w'/'x'. If a region is not shared, it is private, so a 'p' will appear instead of an 's'. If the process attempts to access memory in a way that is not permitted, a segmentation fault is generated. Permissions can be changed using the mprotect system call.
• offset - If the region was mapped from a file (using mmap), this is the offset in the file where the mapping begins. If the memory was not mapped from a file, it's just 0.
• device - If the region was mapped from a file, this is the major and minor device number (in hex) where the file lives.
• inode - If the region was mapped from a file, this is the file number.
• pathname - If the region was mapped from a file, this is the name of the file. This field is blank for anonymous mapped regions. There are also special regions with names like [heap], [stack], or [vdso]. [vdso] stands for virtual dynamic shared object. It's used by system calls to switch to kernel mode. Here's a good article about it.!

You might notice a lot of anonymous regions. These are usually created by mmap but are not attached to any file. They are used for a lot of miscellaneous things like shared memory or buffers not allocated on the heap. For instance, I think the pthread library uses anonymous mapped regions as stacks for new threads.