Memory Address Mapping

[Ashwin Shashidharan]

Is there any way to get to know through a C program memory mapping as done by the OS? The program should be able to query and find out the address range for each of the segments (DS, ES, CS. . .) in an x86 environment. I understand the proc filesystem allows us to determine memory details as used by the process. Any idea here?

[Jyoti Sharma]

I know of these system call: sbrk, sstk (on FreeBSD), check getrlimit also.

The segment business is dependent on the binary format (like, a.out/ELF/COFF/etc) and the compiler (options) as well. Am I right here?

 

Regards,

Jyoti

[Ashwin Shashidharan]

Typically segmentation is handled by the OS hence, the dependence on the generated binary formats.

• a.out on a Linux m/c (I am not sure but can it be generalized to all OS's that use glibc?)
• ELF is distinctive of Unix and Unix-like systems.
• COFF on a few Unix variations, MS Windows and for certain firmware.

Segmentation is one of the most common ways to provide memory protection along with the MMU that is directly responsible for translation and management. The OS's role is to raise(and handle) an exception when a certain segment (or page is not in memory) and provides the necessary routines to load it to main memory.

I found a cheeky program here to identify the listing of memory areas used by a process (The identification was necessary as organization of memory segments for processes is OS dependent).

Thanks for the pointers Jyoti! :)

Regards
Ashwin S

[Jyoti Sharma]

That is good! Yeah that is the closest that we can get. Hoping that
there are all actually all those segments and the compilers/os takes
memory in the same direction for each segment. I mean, for example, in
a particular AIX the stack and the heap grow from the opposite ends of
a region and (obviously) they will be in same address space... fancy a
collision?

Here is some output on different Unix. No windows here. :-)

1.(0xbfc5af74) stack
2.(0x0804a008) heap
3.(0x080497a4) bss
4.(0x08048650) const's
5.(0x08048538) code
Linux 2.6.24-27-generic #1 SMP Mon Apr 12 06:05:30 UTC 2010 i686 GNU/Linux

1.(0xffffeb04) stack
2.(0x00902090) heap
3.(0x00500a70) bss
4.(0x004009b0) const's
5.(0x00400890) code
FreeBSD 7.3-RELEASE FreeBSD 7.3-RELEASE #0: Sun Mar 21 05:25:24 UTC
2010 ro...@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC
amd64

1.(0xffbffc20) stack
2.(0x000212b8) heap
3.(0x00021100) bss
4.(0x00010f68) const's
5.(0x00010ec0) code
SunOS 5.10 Generic_137111-08 sun4v sparc SUNW,Sun-Fire-T1000

1.(0x7f7f0a38) stack
2.(0x40003218) heap
3.(0x4000113a) code
4.(0x40001098) const's
5.(0x40001080) bss
HP-UX B.11.11 U 9000/800 744301393 unlimited-user license

1.(0x2ff228ec) stack
2.(0x20000888) heap
3.(0x200007d0) code
4.(0x200007a8) bss
5.(0x10000720) const's
AIX 3 5 00CE423B4C00

[Ashwin Shashidharan]

etext edata end - The addresses of these symbols indicate the end of various program segments

I found this on doing some further search. Any idea if we can use this anyway to access Kernel segments?

[Jyoti Sharma]

http://stackoverflow.com/questions/1765969/unable-to-locate-definition-of-etext-edata-end

http://www.linux.com/learn/docs/man/etext3

 

 

This is something Unix (flavor) specific. I do not know how reliable they are anymore. If your system man page says it works as advertised then it should be okay.

Do you want to access the kernel segment with raw pointers? System calls and kernel space modules (insmod) do cause operations in kernel space.

Do you want to get the memory used by the kernel for itself during bootup? Some verbose flag (-v) to the kernel in the grub.conf or lilo.conf should give you more descriptive lines from the kernel during bootup. Try this out.

 

Regards,

Jyoti

[Mickey]

Oooo, replying to group via mail makes it look ugly....

Ashwin,

I found something that might interest you here:
http://wiki.freebsd.org/ZFSTuningGuide

#!/bin/sh -

TEXT=`kldstat | awk 'BEGIN {print "16i 0";} NR>1 {print toupper($4)
"+"} END {print "p"}' | dc`
DATA=`vmstat -m | sed -Ee '1s/.*/0/;s/.* ([0-9]+)K.*/\1+/;$s/$/
1024*p/' | dc`
TOTAL=$((DATA + TEXT))

echo TEXT=$TEXT, `echo $TEXT | awk '{print $1/1048576 " MB"}'`
echo DATA=$DATA, `echo $DATA | awk '{print $1/1048576 " MB"}'`
echo TOTAL=$TOTAL, `echo $TOTAL | awk '{print $1/1048576 " MB"}'`

Regards,
Jyoti

On Aug 31, 5:56 am, "Jyoti Sharma" <jyoti.mic...@gmail.com> wrote:
> http://stackoverflow.com/questions/1765969/unable-to-locate-definitio...http://www.linux.com/learn/docs/man/etext3

>
> This is something Unix (flavor) specific. I do not know how reliable they are anymore. If your system man page says it works as advertised then it should be okay.
> Do you want to access the kernel segment with raw pointers? System calls and kernel space modules (insmod) do cause operations in kernel space.
> Do you want to get the memory used by the kernel for itself during bootup? Some verbose flag (-v) to the kernel in the grub.conf or lilo.conf should give you more descriptive lines from the kernel during bootup. Try this out.
>
> Regards,
> Jyoti
>
> From: Ashwin Shashidharan
> Sent: Tuesday, August 31, 2010 6:02 AM
> To: nextge...@googlegroups.com
> Subject: Re: Memory Address Mapping
>
>   etext edata end - The addresses of these symbols indicate the end of various program segments
>
> I found this on doing some further search. Any idea if we can use this anyway to access Kernel segments?
>

> On 25 August 2010 15:38, Jyoti Sharma <jyoti.mic...@gmail.com> wrote:
>
>   That is good! Yeah that is the closest that we can get. Hoping that
>   there are all actually all those segments and the compilers/os takes
>   memory in the same direction for each segment. I mean, for example, in
>   a particular AIX the stack and the heap grow from the opposite ends of
>   a region and (obviously) they will be in same address space... fancy a
>   collision?
>
>   Here is some output on different Unix. No windows here. :-)
>
>   1.(0xbfc5af74) stack
>   2.(0x0804a008) heap
>   3.(0x080497a4) bss
>   4.(0x08048650) const's
>   5.(0x08048538) code
>   Linux 2.6.24-27-generic #1 SMP Mon Apr 12 06:05:30 UTC 2010 i686 GNU/Linux
>
>   1.(0xffffeb04) stack
>   2.(0x00902090) heap
>   3.(0x00500a70) bss
>   4.(0x004009b0) const's
>   5.(0x00400890) code
>   FreeBSD  7.3-RELEASE FreeBSD 7.3-RELEASE #0: Sun Mar 21 05:25:24 UTC

>   2010     r...@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC

>   amd64
>
>   1.(0xffbffc20) stack
>   2.(0x000212b8) heap
>   3.(0x00021100) bss
>   4.(0x00010f68) const's
>   5.(0x00010ec0) code
>   SunOS 5.10 Generic_137111-08 sun4v sparc SUNW,Sun-Fire-T1000
>
>   1.(0x7f7f0a38) stack
>   2.(0x40003218) heap
>   3.(0x4000113a) code
>   4.(0x40001098) const's
>   5.(0x40001080) bss
>   HP-UX  B.11.11 U 9000/800 744301393 unlimited-user license
>
>   1.(0x2ff228ec) stack
>   2.(0x20000888) heap
>   3.(0x200007d0) code
>   4.(0x200007a8) bss
>   5.(0x10000720) const's
>   AIX 3 5 00CE423B4C00
>