Why does the general program usually start at 0x8000?

Question

I am not new to bootloader and system SW, but I don't know the origin of the reason why the general program starts at 0x8000. I already know the address 0x8000 has been used as start address in normal C/C++ program.

Does the minimum size of the bootloader for a general program take up to 0x8000? Or is the minimum block size of ROM that should be allocated to the bootloader 32KB? Or is there another reason?

I'd like to know about this, historically or logically, and from a virtual address point of view.

---

I appreciate all, your time and help with this. To make question more clear, the question is related with virtual address not with physical.

I basically agree with R's opinion from physical memory address point of view.

Without saying a specific system which is diverse, for example linux (even in android), general RTOS (nucleus, and the others, especially ARM linker section), they all use address 0x8000 as start address general program. such named as crt_begin.o, crt.o, etc located at 0x0 with loader exist in this area.

Therefore I guess the minimum size of the bootloader for general program is 32KB considering block size if it would be located at BootROM in boot time(cold boot).

Ummm, But I am not sure...

Answer 1

In general, on all but the smallest embedded systems, the platform ABI designer wants to avoid ever having the lowest addresses in use so that null pointer dereferences can be trapped. Having several KB of never-valid addresses gives you some additional safety if the null pointer is dereferenced with an array or structure member offset, as in null_ptr->some_member.

Answer 2

It depends on the system, and programs start at different addresses on different systems. Under Unix, it's usual (or maybe even required by Posix) to use the address 0 as the null pointer, and to not map the first page of virtual memory, so that dereferencing a null pointer will result in a segment violation. I suspect that other systems using address 0 as a null pointer behave similarly (but how much they reserve may vary). (Historically, it was usual to map the first page as read only, and fill it with zeros, do that a null pointer would behave as if it were an empty string, a pointer to "". That's going back about 25 years, however.)

I would expect that even today, some embedded systems do load the program starting at the address 0.

Answer 3

It's somewhat arbitrary, and on linux, at least decided by the linker. The general idea is to reserve some space to catch NULL pointer exceptions. To help prevent kernel space NULL pointer dereferences from executing arbitrary user code in kernel mode, linux prevents you from mapping the very bottom of memory. /proc/sys/vm/mmap_min_addr controls the lowest address you may map (you can change it to 0 and map a page at 0 if you like).

On linux you can look at the memory mapping by looking in /proc. For example,

genwitt ~> cat /proc/self/maps 
00400000-0040c000 r-xp 00000000 08:01 354804                             /bin/cat
0060b000-0060c000 r--p 0000b000 08:01 354804                             /bin/cat
0060c000-0060d000 rw-p 0000c000 08:01 354804                             /bin/cat
01dda000-01dfb000 rw-p 00000000 00:00 0                                  [heap]
7f5b25913000-7f5b25a97000 r-xp 00000000 08:01 435953                     /lib64/libc-2.14.1.so
7f5b25a97000-7f5b25c97000 ---p 00184000 08:01 435953                     /lib64/libc-2.14.1.so
7f5b25c97000-7f5b25c9b000 r--p 00184000 08:01 435953                     /lib64/libc-2.14.1.so
7f5b25c9b000-7f5b25c9c000 rw-p 00188000 08:01 435953                     /lib64/libc-2.14.1.so
7f5b25c9c000-7f5b25ca1000 rw-p 00000000 00:00 0 
7f5b25ca1000-7f5b25cc2000 r-xp 00000000 08:01 436061                     /lib64/ld-2.14.1.so
7f5b25cd2000-7f5b25e97000 r--p 00000000 08:01 126248                     /usr/lib64/locale/locale-archive
7f5b25e97000-7f5b25e9a000 rw-p 00000000 00:00 0 
7f5b25ec0000-7f5b25ec1000 rw-p 00000000 00:00 0 
7f5b25ec1000-7f5b25ec2000 r--p 00020000 08:01 436061                     /lib64/ld-2.14.1.so
7f5b25ec2000-7f5b25ec3000 rw-p 00021000 08:01 436061                     /lib64/ld-2.14.1.so
7f5b25ec3000-7f5b25ec4000 rw-p 00000000 00:00 0 
7fff18c37000-7fff18c58000 rw-p 00000000 00:00 0                          [stack]
7fff18d0c000-7fff18d0d000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]