Linux-Development-Sys Digest #689, Volume #7 Mon, 20 Mar 00 02:13:14 EST
Contents:
Re: GNU C compiler source code (Andy Guibert)
Re: tricky code in super.c (Andy Guibert)
Re: GNU C compiler source code (again... sorry) (Andy Guibert)
Re: To Linyx pl....help help (Andy Guibert)
Re: Bootdisks, rdev, and root filesystems...aargh! (Dances With Crows)
Re: GNU C compiler source code (Andy Guibert)
directory entry reclaim? (Weiguang Shi)
Re: sock_sendmsg() (Dan McGuirk)
Partitionable Devices & Rubini (Mark McDougall)
User process virtual memory layout (Sean R. Manning)
Re: how to write/read sector to hd? (Pete Cavender)
Re: Xserver problem (Mario Klebsch)
Re: User process virtual memory layout ("Arthur H. Gold")
Re: User process virtual memory layout (Sean R. Manning)
----------------------------------------------------------------------------
From: Andy Guibert <[EMAIL PROTECTED]>
Subject: Re: GNU C compiler source code
Date: Sun, 19 Mar 2000 18:34:10 -0500
Qui Nguyen wrote:
> Hi all,
> I want to know whether GNU C compiler source code is free or not. If
> it's free
> where I can download it.
> Thanks in advance
I've yet to see GNU software that isn't GPL'ed.
I usually download gcc from the Linux Kernel archives:
http://www.kernel.org/pub/linux/devel/gcc/
--
=================================================
Remove the "nojunk" from my addy when responding.
"May the source be with you, Luke."
------------------------------
From: Andy Guibert <[EMAIL PROTECTED]>
Subject: Re: tricky code in super.c
Date: Sun, 19 Mar 2000 18:38:34 -0500
Weiguang Shi wrote:
> I am reading the code of /usr/src/linux/fs/super.c of version 2.0.38.
> At line 443, there is "s = 0+super_blocks;". I don't know why this is the
> way it is. Would a simple "s=super_blocks;" hurt?
Though it does make the code look cleaner, I do not think that it affects the
compiled binary. If I'm not mistaken, gcc is an optimizing compiler and takes
out inefficiencies such as this one.
--
=================================================
Remove the "nojunk" from my addy when responding.
"May the source be with you, Luke."
------------------------------
From: Andy Guibert <[EMAIL PROTECTED]>
Subject: Re: GNU C compiler source code (again... sorry)
Date: Sun, 19 Mar 2000 18:55:39 -0500
You can also get GCC directly from the GNU ftp site.
ftp.gnu.org
Andy
=================================================
Remove the "nojunk" from my addy when responding.
"May the source be with you, Luke."
------------------------------
From: Andy Guibert <[EMAIL PROTECTED]>
Subject: Re: To Linyx pl....help help
Date: Sun, 19 Mar 2000 19:06:14 -0500
"Bass¨Ð¦õªv" wrote:
> can I do this between "iMac (and other's apple ¾÷) " and "linux" ???
> How can I do this ???
You're looking for something called Appletalk DDP. It's support can be
compiled into the kernel.
Scope out http://www.eats.com/linux_mac_win/file_services.html for
details.
=================================================
Remove the "nojunk" from my addy when responding.
"May the source be with you, Luke."
------------------------------
From: [EMAIL PROTECTED] (Dances With Crows)
Crossposted-To: alt.os.linux,comp.os.linux.misc
Subject: Re: Bootdisks, rdev, and root filesystems...aargh!
Date: 19 Mar 2000 19:06:24 EST
Reply-To: [EMAIL PROTECTED]
On 19 Mar 2000 22:09:20 GMT, Dennis Heltzel
<<01bf91f0$c15ded00$790a1aac@server>> shouted forth into the ether:
>You need to use a bootmanager like lilo or syslinux to uncompress the root
>FS into a RAM
>disk and then load the kernel into memory. I've used syslinux for this
>quite successfully
Sorry... While lilo or syslinux might make working with RAMdisks a bit
easier, there's no pressing need to use it. All is explained in the
Bootdisk-HOWTO:
http://www.linuxdoc.org/HOWTO/Bootdisk-HOWTO.html
(Besides, being able to mutter weird-looking rdev incantations has more
Hack Value, y'know!)
--
Matt G / Dances With Crows \###| Programmers are playwrights
There is no Darkness in Eternity \##| Computers are lousy actors
But only Light too dim for us to see \#| Lusers are vicious drama critics
(Unless, of course, you're working with NT)\| BOFHen burn down theatres.
------------------------------
From: Andy Guibert <[EMAIL PROTECTED]>
Subject: Re: GNU C compiler source code
Date: Sun, 19 Mar 2000 19:18:04 -0500
Qui Nguyen wrote:
> Hi all,
> I want to know whether GNU C compiler source code is free or not. If
> it's free
> where I can download it.
Have you tried ftp.gnu.org? :)
=================================================
Remove the "nojunk" from my addy when responding.
"May the source be with you, Luke."
------------------------------
From: Weiguang Shi <[EMAIL PROTECTED]>
Subject: directory entry reclaim?
Date: Sun, 19 Mar 2000 17:22:57 -0700
Hi, there:
As I am reading the filesystem code of 2.0.38, it occurs to me that
the file systems (minix and ext2) do not reclaim the directory entries.
When an entry is deleted, the inode number is set to 0. This is
simple and efficient. But what if there is a directory with hundreds of
thounds of entries at a time gets all the files under it removed? This
will leave the directory file un-shrinked and thus wastes disk space.
Could someone point out I am right or wrong?
Thanks a lot.
Weiguang
------------------------------
From: Dan McGuirk <[EMAIL PROTECTED]>
Subject: Re: sock_sendmsg()
Date: Sun, 19 Mar 2000 17:25:45 -0800
James Emil Avery wrote:
> Using sock_sendmsg(), I get a strange behaviour: If I set the length
> parameter of sock_sendmsg() to 0, a message is sent and registered on the
> other end. If it is nonzero, an EFAULT (invalid address) is returned --
> obviously not true, since the null-message comes through fine.
The problem is that the buffer containing the data you're trying to send
is in kernel memory, and the sendmsg() routines expect it to be in user
memory. If you could get a pointer to a user memory buffer somehow and
use that, I suppose what you're trying to do could work.
--
Dan McGuirk
[EMAIL PROTECTED]
------------------------------
From: Mark McDougall <[EMAIL PROTECTED]>
Subject: Partitionable Devices & Rubini
Date: Mon, 20 Mar 2000 12:53:10 +1100
Hi all,
I'm having a frustrating time implementing a partitionable device
driver.
I've had a (non-partitionable) driver running for some months now, based
originally on Rubini's "sbull" example source.
Recently I've attempted to add partitioning support to the driver and
have had no end of trouble. I'm following his example in the book...
I notice that his "spull" device does not use the blksize and hardsect
arrays. My driver was crashing without these allocated. Also, I needed
an entry for each partition, not just each device. Should I need these?
Now I can seemingly create two partitions on my device, but any attempt
to use either invariably ends up corrupting the other partition. I would
normally suspect my code that maintains sector boundaries for each
partition but I'm receiving read/write requests (regularly) for the
wrong partition (as seen in MINOR(CURRENT_DEV) in my request function).
Any idea what could possibly be wrong? Anyone else successfully
implemented partitioning based on Rubini's book? I'm at wit's end. :(
TIA,
Regards,
--
| Mark McDougall |
| Engineer |
| Virtual Logic Pty Ltd |
| http://www.vl.com.au |
------------------------------
From: [EMAIL PROTECTED] (Sean R. Manning)
Crossposted-To: comp.unix.programmer
Subject: User process virtual memory layout
Date: Mon, 20 Mar 2000 04:10:42 GMT
Hello,
I'm trying to nail down what the memory layout is for a Linux's user
process. I've been searching all over and the best I could come up
with was a very old (referred to about kernel 0.99) picture that was
in the Linux Kernel Hacker's Guide.
(http://khg.redhat.com/HyperNews/get/khg.html) The page said that it
was probably still applicable to the more current kernels, but even
then it was largely incomplete. Below is how it said the virtual
memory is partitioned:
Start Address Description
============= ===========
0xC0000000 The invisible kernel
0x???????? Initial stack
0x???????? Room for stack growth
0x60000000 Shared libraries
0x???????? brk - unused
0x???????? malloc memory
0x???????? Uninitialized data
0x???????? Initialized data
0x00000000 Text
What sparked my interest in knowing the layout (aside from just
wanting to know everything that there is to know) was to answer the
question that I always have when using a debugger. The question is,
why is it that the text supposedly starts from 0x00000000 and works
its way up, but when you use a debugger to single step through a
program, if you notice the addresses of the instructions you'll see
that they are in the 0x8000000 vicinity. Also if you use one of the
bin tools to look at the ELF executable file to see where the linker
has told it to load the .text area you'll see the same thing. I'm
sure there's probably some easy answer to this, but I just can't seem
to locate it on the Internet. So maybe one of you guru's can set me
straight on the reason for this. And if I'm lucky, maybe you can even
tell me where the current user process memory layout is documented.
Thanks so much.
Sean Manning
------------------------------
From: [EMAIL PROTECTED] (Pete Cavender)
Subject: Re: how to write/read sector to hd?
Date: Mon, 20 Mar 2000 04:26:10 GMT
In article <8b3j0l$51l$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> Hi,
> I am desperately trying to find a very simple low level function that
> writes and reads to any part of the hard drive.
> I have a 2nd, empty, ext2 hard drive mounted to /db/ directory.
> I am using gnu gcc and cannot use functions such as fopen because it is
> not efficient enough. I need to use the entire hard disk as one big
> binary; i.e., 50Gb of data.
> I know how to do this in dos by simply calling the bios routine to
> write or read at any sector on the hard drive, but I would much rather
> stay
> away from dos ;-)
> Currently I am looking into the ll_rw_block() function but I have no
> idea if this is the correct or proper function.
> Thanks for the help in advanced!!
> Paul_L
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
open("/dev/hdc1"...)
------------------------------
From: [EMAIL PROTECTED] (Mario Klebsch)
Subject: Re: Xserver problem
Date: Sun, 19 Mar 2000 19:19:17 +0100
"Dimitry Katkov" <[EMAIL PROTECTED]> writes:
>I am trying to run LEM (Linux - embedded) and the problem raised when I am
>trying to 'startx'. It tells me
>'Fatal server error:
>could not open default font 'fixed'
You probably did not configure the font path correctly. To bootstrap
the system, it could be easy to install a font server on a running
Linux/X11 system and use that font server als the only component in
the font path. This proibably is not the perfect sollution, but does
eliminate possible problems with your local file system or with byte
order dependencies.
73, Mario
--
Mario Klebsch [EMAIL PROTECTED]
------------------------------
Date: Sun, 19 Mar 2000 23:46:55 +0000
From: "Arthur H. Gold" <[EMAIL PROTECTED]>
Crossposted-To: comp.unix.programmer
Subject: Re: User process virtual memory layout
"Sean R. Manning" wrote:
>
> Hello,
>
> I'm trying to nail down what the memory layout is for a Linux's user
> process. I've been searching all over and the best I could come up
> with was a very old (referred to about kernel 0.99) picture that was
> in the Linux Kernel Hacker's Guide.
> (http://khg.redhat.com/HyperNews/get/khg.html) The page said that it
> was probably still applicable to the more current kernels, but even
> then it was largely incomplete. Below is how it said the virtual
> memory is partitioned:
>
> Start Address Description
> ============= ===========
>
> 0xC0000000 The invisible kernel
> 0x???????? Initial stack
> 0x???????? Room for stack growth
> 0x60000000 Shared libraries
> 0x???????? brk - unused
> 0x???????? malloc memory
> 0x???????? Uninitialized data
> 0x???????? Initialized data
> 0x00000000 Text
>
> What sparked my interest in knowing the layout (aside from just
> wanting to know everything that there is to know) was to answer the
> question that I always have when using a debugger. The question is,
> why is it that the text supposedly starts from 0x00000000 and works
> its way up, but when you use a debugger to single step through a
> program, if you notice the addresses of the instructions you'll see
> that they are in the 0x8000000 vicinity. Also if you use one of the
> bin tools to look at the ELF executable file to see where the linker
> has told it to load the .text area you'll see the same thing. I'm
> sure there's probably some easy answer to this, but I just can't seem
> to locate it on the Internet. So maybe one of you guru's can set me
> straight on the reason for this. And if I'm lucky, maybe you can even
> tell me where the current user process memory layout is documented.
> Thanks so much.
>
> Sean Manning
Assuming your system has the /proc filesystem enabled (it should), do a
'cat /proc/<pid>/maps' (where <pid> is the process id of some running
process). That will show you the memory layout for the given process.
For example, the following is the maps file for the copy of netscape I'm
writing this in:
08048000-08b03000 r-xp 00000000 03:03 196189 /opt/netscape/netscape
08b03000-08d73000 rw-p 00aba000 03:03 196189 /opt/netscape/netscape
08d73000-0960f000 rwxp 00000000 00:00 0
40000000-40013000 r-xp 00000000 03:03 479920 /lib/ld-2.1.2.so
40013000-40014000 rw-p 00012000 03:03 479920 /lib/ld-2.1.2.so
40014000-40015000 rwxp 00000000 00:00 0
40015000-40016000 r-xp 00000000 03:03 479923 /lib/libNoVersion.so.1
40016000-40017000 rw-p 00000000 03:03 479923 /lib/libNoVersion.so.1
40017000-40019000 rw-p 00000000 00:00 0
40019000-4001c000 r-xp 00000000 16:44 36928
/usr/local/lib/libnss_dns-2.1.2.so
4001c000-4001d000 rw-p 00002000 16:44 36928
/usr/local/lib/libnss_dns-2.1.2.so
4001d000-4001e000 rw-p 00000000 00:00 0
40023000-40024000 r-xp 00000000 16:44 36905
/usr/local/lib/libBrokenLocale-2.1.2.so
40024000-40025000 rw-p 00000000 16:44 36905
/usr/local/lib/libBrokenLocale-2.1.2.so
40025000-4006a000 r-xp 00000000 16:41 76172
/usr/X11R6/lib/libXt.so.6.0
4006a000-4006e000 rw-p 00044000 16:41 76172
/usr/X11R6/lib/libXt.so.6.0
4006e000-4006f000 rw-p 00000000 00:00 0
4006f000-40076000 r-xp 00000000 16:41 76148
/usr/X11R6/lib/libSM.so.6.0
40076000-40078000 rw-p 00006000 16:41 76148
/usr/X11R6/lib/libSM.so.6.0
40078000-40079000 rw-p 00000000 00:00 0
40079000-4008b000 r-xp 00000000 16:41 76142
/usr/X11R6/lib/libICE.so.6.3
4008b000-4008d000 rw-p 00011000 16:41 76142
/usr/X11R6/lib/libICE.so.6.3
4008d000-4008f000 rw-p 00000000 00:00 0
4008f000-400a0000 r-xp 00000000 16:41 76166
/usr/X11R6/lib/libXmu.so.6.0
400a0000-400a1000 rw-p 00010000 16:41 76166
/usr/X11R6/lib/libXmu.so.6.0
400a1000-400ae000 r-xp 00000000 16:41 76139
/usr/X11R6/lib/libXpm.so.4.11
400ae000-400af000 rw-p 0000c000 16:41 76139
/usr/X11R6/lib/libXpm.so.4.11
400af000-400b9000 r-xp 00000000 16:41 76160
/usr/X11R6/lib/libXext.so.6.3
400b9000-400bb000 rw-p 00009000 16:41 76160
/usr/X11R6/lib/libXext.so.6.3
400bb000-4015a000 r-xp 00000000 16:41 76151
/usr/X11R6/lib/libX11.so.6.1
4015a000-40161000 rw-p 0009e000 16:41 76151
/usr/X11R6/lib/libX11.so.6.1
40161000-40163000 r-xp 00000000 16:44 36959
/usr/local/lib/libdl-2.1.2.so
40163000-40164000 rw-p 00001000 16:44 36959
/usr/local/lib/libdl-2.1.2.so
40164000-40165000 rw-p 00000000 00:00 0
40165000-40196000 r-xp 00000000 16:41 29009
/usr/lib/libstdc++.so.2.8
40196000-401a4000 rw-p 00030000 16:41 29009
/usr/lib/libstdc++.so.2.8
401a4000-401a6000 rw-p 00000000 00:00 0
401a6000-401c2000 r-xp 00000000 16:44 36909
/usr/local/lib/libm-2.1.2.so
401c2000-401c3000 rw-p 0001b000 16:44 36909
/usr/local/lib/libm-2.1.2.so
401c3000-402b7000 r-xp 00000000 16:44 36964
/usr/local/lib/libc-2.1.2.so
402b7000-402bb000 rw-p 000f3000 16:44 36964
/usr/local/lib/libc-2.1.2.so
402bb000-402bf000 rw-p 00000000 00:00 0
402bf000-402c7000 r-xp 00000000 16:44 36932
/usr/local/lib/libnss_files-2.1.2.so
402c7000-402c8000 rw-p 00007000 16:44 36932
/usr/local/lib/libnss_files-2.1.2.so
402d4000-402df000 r-xp 00000000 16:44 36926
/usr/local/lib/libresolv-2.1.2.so
402df000-402e1000 rw-p 0000a000 16:44 36926
/usr/local/lib/libresolv-2.1.2.so
402e1000-402e3000 rw-p 00000000 00:00 0
50000000-50002000 ---p 00000000 03:03 34006 /dev/zero
50002000-50012000 rwxp 00002000 03:03 34006 /dev/zero
50012000-50014000 ---p 00012000 03:03 34006 /dev/zero
50014000-50016000 ---p 00000000 03:03 34006 /dev/zero
50016000-50026000 rwxp 00002000 03:03 34006 /dev/zero
50026000-50028000 ---p 00012000 03:03 34006 /dev/zero
bfff7000-c0000000 rwxp ffff8000 00:00 0
In general, the layout is:
program code
program static data
heap
<gap for heap growth>
libraries needed at initialization (code, static, and sometimes some
other space)
mmapped areas (for alt stack, files, etc.)
<gap for additional mmapped areas>
stack (which grown _down_ in the address space).
HTH,
--ag
--
Artie Gold, Austin, TX (finger the cs.utexas.edu account for more info)
mailto:[EMAIL PROTECTED] or mailto:[EMAIL PROTECTED]
--
A: Look for a lawyer who speaks Aramaic...about trademark infringement.
------------------------------
From: [EMAIL PROTECTED] (Sean R. Manning)
Crossposted-To: comp.unix.programmer
Subject: Re: User process virtual memory layout
Date: Mon, 20 Mar 2000 06:40:47 GMT
Thanks for the tip. The results of your print out illustrate the
other part of my question. Specifically, they show that the .text
area of the netscape process are located at 0x08048000-0x08b03000. As
you pointed out, the .text (program code) is loaded first in the lower
memory address. However, why would it not be loaded starting at
0x00000000? Or at least somewhere much lower than 0x08048000.
Thanks.
Sean
On Sun, 19 Mar 2000 23:46:55 +0000, "Arthur H. Gold" <[EMAIL PROTECTED]>
wrote:
>Assuming your system has the /proc filesystem enabled (it should), do a
>'cat /proc/<pid>/maps' (where <pid> is the process id of some running
>process). That will show you the memory layout for the given process.
>
>For example, the following is the maps file for the copy of netscape I'm
>writing this in:
>
>08048000-08b03000 r-xp 00000000 03:03 196189 /opt/netscape/netscape
>08b03000-08d73000 rw-p 00aba000 03:03 196189 /opt/netscape/netscape
>08d73000-0960f000 rwxp 00000000 00:00 0
>40000000-40013000 r-xp 00000000 03:03 479920 /lib/ld-2.1.2.so
>40013000-40014000 rw-p 00012000 03:03 479920 /lib/ld-2.1.2.so
>40014000-40015000 rwxp 00000000 00:00 0
>40015000-40016000 r-xp 00000000 03:03 479923 /lib/libNoVersion.so.1
>40016000-40017000 rw-p 00000000 03:03 479923 /lib/libNoVersion.so.1
>40017000-40019000 rw-p 00000000 00:00 0
>40019000-4001c000 r-xp 00000000 16:44 36928
>/usr/local/lib/libnss_dns-2.1.2.so
>4001c000-4001d000 rw-p 00002000 16:44 36928
>/usr/local/lib/libnss_dns-2.1.2.so
>4001d000-4001e000 rw-p 00000000 00:00 0
>40023000-40024000 r-xp 00000000 16:44 36905
>/usr/local/lib/libBrokenLocale-2.1.2.so
>40024000-40025000 rw-p 00000000 16:44 36905
>/usr/local/lib/libBrokenLocale-2.1.2.so
>40025000-4006a000 r-xp 00000000 16:41 76172
>/usr/X11R6/lib/libXt.so.6.0
>4006a000-4006e000 rw-p 00044000 16:41 76172
>/usr/X11R6/lib/libXt.so.6.0
>4006e000-4006f000 rw-p 00000000 00:00 0
>4006f000-40076000 r-xp 00000000 16:41 76148
>/usr/X11R6/lib/libSM.so.6.0
>40076000-40078000 rw-p 00006000 16:41 76148
>/usr/X11R6/lib/libSM.so.6.0
>40078000-40079000 rw-p 00000000 00:00 0
>40079000-4008b000 r-xp 00000000 16:41 76142
>/usr/X11R6/lib/libICE.so.6.3
>4008b000-4008d000 rw-p 00011000 16:41 76142
>/usr/X11R6/lib/libICE.so.6.3
>4008d000-4008f000 rw-p 00000000 00:00 0
>4008f000-400a0000 r-xp 00000000 16:41 76166
>/usr/X11R6/lib/libXmu.so.6.0
>400a0000-400a1000 rw-p 00010000 16:41 76166
>/usr/X11R6/lib/libXmu.so.6.0
>400a1000-400ae000 r-xp 00000000 16:41 76139
>/usr/X11R6/lib/libXpm.so.4.11
>400ae000-400af000 rw-p 0000c000 16:41 76139
>/usr/X11R6/lib/libXpm.so.4.11
>400af000-400b9000 r-xp 00000000 16:41 76160
>/usr/X11R6/lib/libXext.so.6.3
>400b9000-400bb000 rw-p 00009000 16:41 76160
>/usr/X11R6/lib/libXext.so.6.3
>400bb000-4015a000 r-xp 00000000 16:41 76151
>/usr/X11R6/lib/libX11.so.6.1
>4015a000-40161000 rw-p 0009e000 16:41 76151
>/usr/X11R6/lib/libX11.so.6.1
>40161000-40163000 r-xp 00000000 16:44 36959
>/usr/local/lib/libdl-2.1.2.so
>40163000-40164000 rw-p 00001000 16:44 36959
>/usr/local/lib/libdl-2.1.2.so
>40164000-40165000 rw-p 00000000 00:00 0
>40165000-40196000 r-xp 00000000 16:41 29009
>/usr/lib/libstdc++.so.2.8
>40196000-401a4000 rw-p 00030000 16:41 29009
>/usr/lib/libstdc++.so.2.8
>401a4000-401a6000 rw-p 00000000 00:00 0
>401a6000-401c2000 r-xp 00000000 16:44 36909
>/usr/local/lib/libm-2.1.2.so
>401c2000-401c3000 rw-p 0001b000 16:44 36909
>/usr/local/lib/libm-2.1.2.so
>401c3000-402b7000 r-xp 00000000 16:44 36964
>/usr/local/lib/libc-2.1.2.so
>402b7000-402bb000 rw-p 000f3000 16:44 36964
>/usr/local/lib/libc-2.1.2.so
>402bb000-402bf000 rw-p 00000000 00:00 0
>402bf000-402c7000 r-xp 00000000 16:44 36932
>/usr/local/lib/libnss_files-2.1.2.so
>402c7000-402c8000 rw-p 00007000 16:44 36932
>/usr/local/lib/libnss_files-2.1.2.so
>402d4000-402df000 r-xp 00000000 16:44 36926
>/usr/local/lib/libresolv-2.1.2.so
>402df000-402e1000 rw-p 0000a000 16:44 36926
>/usr/local/lib/libresolv-2.1.2.so
>402e1000-402e3000 rw-p 00000000 00:00 0
>50000000-50002000 ---p 00000000 03:03 34006 /dev/zero
>50002000-50012000 rwxp 00002000 03:03 34006 /dev/zero
>50012000-50014000 ---p 00012000 03:03 34006 /dev/zero
>50014000-50016000 ---p 00000000 03:03 34006 /dev/zero
>50016000-50026000 rwxp 00002000 03:03 34006 /dev/zero
>50026000-50028000 ---p 00012000 03:03 34006 /dev/zero
>bfff7000-c0000000 rwxp ffff8000 00:00 0
>
>In general, the layout is:
>
>program code
>program static data
>heap
><gap for heap growth>
>libraries needed at initialization (code, static, and sometimes some
>other space)
>mmapped areas (for alt stack, files, etc.)
><gap for additional mmapped areas>
>stack (which grown _down_ in the address space).
>
>HTH,
>--ag
>--
>Artie Gold, Austin, TX (finger the cs.utexas.edu account for more info)
>mailto:[EMAIL PROTECTED] or mailto:[EMAIL PROTECTED]
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
