To quote from a book: A specific starting address is specified for each architecture: IA-32 systems start at 0x08048000, leaving a gap of roughly 128 MiB between the lowest possible address and the start of the text mapping that is used to catch NULL pointers. Other architectures keep a similar hole: UltraSparc machines use 0x100000000 as the starting point of the text segment, while AMD64 uses 0x0000000000400000. The heap starts directly above the text segment and grows upward. In moderne terms these base address may not be important anymore, as gcc will in fact purposely randomize the base address: http://gcc.gnu.org/wiki/Randomization and the logic/rationale is explained in this paper: http://www.usenix.org/events/sec03/tech/full_papers/bhatkar/bhatkar_html/dao002.html But then there are security bug reports describing these randomization opening up more security vulnerabilities than it solved..... Have fun reading..... 2009/2/6 Pei Lin <telent997@xxxxxxxxx>: > hi, > who can give some advice about this question? Because the young > men like me don't know > some history legacy. > > > > ---------- Forwarded message ---------- > From: pei lin <telent998@xxxxxxxxx> > Date: 2009/2/6 > Subject: Re: why linux ELF base address is 0x8048000? > To: Brian Raiter <breadbox@xxxxxxxxxxxxxx> > 抄送： Chris Evans <teknopup@xxxxxxxxx>, linux-assembly@xxxxxxxxxxxxxxx > > > yeah,that explains some reason. But between 0x08000000 and 0x08048000 > should be some other reason for X86 architecture . <<The linker and > loader>> said that "permitting most programs to use a single > second-level page table." > > But i can not understand it very well. > > Lin > > 2009/2/5 Brian Raiter <breadbox@xxxxxxxxxxxxxx>: >>> why linux ELF base address is 0x8048000? we can use ld to change >>> the base address or linker script.BUT why default is 0x8048000? >>> There must be some reasons or history i don't know. >> >> As far as I can tell, the reason is that this was the address used by >> SVR4, which was the first release of Unix to use ELF executables. >> >> The reason that SVR4 chose that particular address is that the stack >> top was located at 0x08000000 (growing downward, of course), and then >> the area between 0x08000000 and 0x08048000 was reserved for libc and >> possibly other system service code. >> >> b >> > > -- > To unsubscribe from this list: send an email with > "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx > Please read the FAQ at http://kernelnewbies.org/FAQ > > -- Regards, Peter Teoh -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
