blocks|key|50519|text|32位小型静态应用程序的x86典型负载图如下所示：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|50520|+Address+++++Contents

+0x08048000++code
+0x08052000++data
+0x0805A000++bss+(zero+data)
+0x08072000++end+of+data+(brk+marker)
+0xBFFFE000++stack|code-block|syntax|javascript|50521|所有这些都在反向堆栈中-在顶部，当数据向上移动时，向下移动。我猜测0x08048000之前的地址是静态链接的，类似于每个操作系统的MBR。|50522|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

Typical Load Map for x86 for 32 bit Small static app looks like :

<pre><code> Address Contents

 0x08048000 code
 0x08052000 data
 0x0805A000 bss (zero data)
 0x08072000 end of data (brk marker)
 0xBFFFE000 stack
</code></pre>

All this being in reverse - stack being on top and moving down while data moving up. My guess is the address before 0x08048000 are statically linked something similar to the MBR per OS.

blocks|key|49298|text|加载可执行代码的起始地址由可执行文件的ELF标头确定。例如：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|49299|/bin/ls
architecture:+i386,+flags+0x00000112:
EXEC_P,+HAS_SYMS,+D_PAGED
start+address+0x08049bb0|code-block|syntax|javascript|49300|没有什么可以阻止可执行文件指定不同的加载地址；无论出于什么原因，default+linker+settings都会将其放在那里。您可以使用自定义链接器脚本重写。|offset|length|49301|默认情况下，在linux/x86上，您不会看到0x08000000下面的低地址被大量使用；尽管如果在mmap调用中请求，或者如果它耗尽了mmap的空间，内核可能会使用它。此外，有人提议将0x00000000+-+0x01000000范围内的地址用于库映射，以使缓冲区溢出更加困难(通过嵌入NUL字节来终止字符串)。|style|CODE|49302|entityMap|0|LINK|mutability|MUTABLE|url|http://google.com/codesearch#56FLpuOUDGc/pub/linux/devel/binutils/binutils-2.17.50.0.14.tar.bz2%257CfwPT3s9w03c/binutils-2.17.50.0.14/ld/emulparams/elf_i386.sh&q=TEXT_START_ADDR=0x08048000%2520package:binutils&type=cs^0|0|0|W|N|0|0|N|A|1E|4|2L|N|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|X|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|Y|8|@]|9|@$I|Z|J|10|1|11]]|A|$]]|$1|K|3|L|5|6|7|12|8|@$I|13|J|14|M|N]|$I|15|J|16|M|N]|$I|17|J|18|M|N]]|9|@]|A|$]]|$1|O|3|-4|5|6|7|19|8|@]|9|@]|A|$]]]|P|$Q|$5|R|S|T|A|$U|V]]]]

The start address for loading executable code is determined by the ELF headers for the executable. For example:

<pre><code>/bin/ls
architecture: i386, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x08049bb0
</code></pre>

There's nothing stopping an executable from specifying a different load address; for whatever reason the <a href="http://google.com/codesearch#56FLpuOUDGc/pub/linux/devel/binutils/binutils-2.17.50.0.14.tar.bz2%7CfwPT3s9w03c/binutils-2.17.50.0.14/ld/emulparams/elf_i386.sh&amp;q=TEXT_START_ADDR=0x08048000%20package:binutils&amp;type=cs" rel="noreferrer">default linker settings</a> put it there. You could override with a custom linker script.

By default, on linux/x86, you won't see low addresses below <code>0x08000000</code> used for much; although the kernel may use it if requested in a <code>mmap</code> call, or if it runs out of room for mmaps. Additionally, there have been proposals to use addresses in the <code>0x00000000 - 0x01000000</code> range for library mappings, to make buffer overflows more difficult (by embedding a NUL byte to terminate strings).

blocks|key|49315|text|答案真的是:一堆东西。可执行文件的加载地址没有什么神奇的意义，几乎任何东西都可以映射到较低的地址。常见的例子包括:C库(如C库)、动态加载器ld.so和内核VDSO+(内核映射的动态代码库，它提供了一些在x86+Linux中对内核的接口)。但是，您几乎可以使用mmap()系统调用在那里映射您想要的任何内容。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|49316|例如，在我的特定机器上，该映射如下所示(已获得，但"cat+/proc/self/maps")：|49317|gby@watson:~$+cat+/proc/self/maps+
001c0000-00317000+r-xp+00000000+08:01+245836+++++/lib/libc-2.12.1.so
00317000-00318000+---p+00157000+08:01+245836+++++/lib/libc-2.12.1.so
00318000-0031a000+r--p+00157000+08:01+245836+++++/lib/libc-2.12.1.so
0031a000-0031b000+rw-p+00159000+08:01+245836+++++/lib/libc-2.12.1.so
0031b000-0031e000+rw-p+00000000+00:00+0+
00376000-00377000+r-xp+00000000+00:00+0++++++++++[vdso]
00852000-0086e000+r-xp+00000000+08:01+245783+++++/lib/ld-2.12.1.so
0086e000-0086f000+r--p+0001b000+08:01+245783+++++/lib/ld-2.12.1.so
0086f000-00870000+rw-p+0001c000+08:01+245783+++++/lib/ld-2.12.1.so
08048000-08051000+r-xp+00000000+08:01+2244617++++/bin/cat
08051000-08052000+r--p+00008000+08:01+2244617++++/bin/cat
08052000-08053000+rw-p+00009000+08:01+2244617++++/bin/cat
09ab5000-09ad6000+rw-p+00000000+00:00+0++++++++++[heap]
b7502000-b7702000+r--p+00000000+08:01+4456455++++/usr/lib/locale/locale-archive
b7702000-b7703000+rw-p+00000000+00:00+0+
b771b000-b771c000+r--p+002a1000+08:01+4456455++++/usr/lib/locale/locale-archive
b771c000-b771e000+rw-p+00000000+00:00+0+
bfbd9000-bfbfa000+rw-p+00000000+00:00+0++++++++++[stack]|code-block|syntax|javascript|49318|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|L|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|M|8|@]|9|@]|A|$G|H]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

The answer is really: a bunch of things. There is no magical meaning to the load address of the executable and pretty much anything can be mapped to the lower addresses. Common examples including: C library (such as the C library), the dynamic loader ld.so and the kernel VDSO (kernel mapped dynamic code library that provides some of the interface to the kernel in x86 Linux). But you can pretty much map anything you desire there, using the mmap() system call.

For example on my specific machine the map is as follows (acquired but "cat /proc/self/maps"):

<pre><code>gby@watson:~$ cat /proc/self/maps 
001c0000-00317000 r-xp 00000000 08:01 245836 /lib/libc-2.12.1.so
00317000-00318000 ---p 00157000 08:01 245836 /lib/libc-2.12.1.so
00318000-0031a000 r--p 00157000 08:01 245836 /lib/libc-2.12.1.so
0031a000-0031b000 rw-p 00159000 08:01 245836 /lib/libc-2.12.1.so
0031b000-0031e000 rw-p 00000000 00:00 0 
00376000-00377000 r-xp 00000000 00:00 0 [vdso]
00852000-0086e000 r-xp 00000000 08:01 245783 /lib/ld-2.12.1.so
0086e000-0086f000 r--p 0001b000 08:01 245783 /lib/ld-2.12.1.so
0086f000-00870000 rw-p 0001c000 08:01 245783 /lib/ld-2.12.1.so
08048000-08051000 r-xp 00000000 08:01 2244617 /bin/cat
08051000-08052000 r--p 00008000 08:01 2244617 /bin/cat
08052000-08053000 rw-p 00009000 08:01 2244617 /bin/cat
09ab5000-09ad6000 rw-p 00000000 00:00 0 [heap]
b7502000-b7702000 r--p 00000000 08:01 4456455 /usr/lib/locale/locale-archive
b7702000-b7703000 rw-p 00000000 00:00 0 
b771b000-b771c000 r--p 002a1000 08:01 4456455 /usr/lib/locale/locale-archive
b771c000-b771e000 rw-p 00000000 00:00 0 
bfbd9000-bfbfa000 rw-p 00000000 00:00 0 [stack]
</code></pre>

blocks|key|2531029|text|加载地址是任意的，但在x86的SYSV中是标准化的。每种架构都是不同的。上面和下面的内容也是任意的，通常由链接库和mmap()区域占用。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2531030|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

The load address is arbitrary, but was standardized back with SYSV for x86. It's different for every architecture. What goes above and below is also arbitrary, and is often taken up by linked in libraries and mmap() regions.

In Linux, I learned that every process stores data starting at 0x08048000 in 32 bit machine (and 0x00400000 in 64 bit machine).

But I don't know the reason why starting from there. What's the memory before 0x08048000 used for?

Update:
Some people think it's mapped for the kernel. However as far as I know, Linux kernel uses the high-end memory starting after the user stack.

What's the memory before 0x08048000 used for in 32 bit machine?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

在Linux中，我了解到每个进程在32位机器中存储从0x08048000开始的数据(在64位机器中从0x00400000开始)。但我不知道为什么要从那里开始。0x08048000之前的内存是做什么用的？更新：有些人认为它是为内核映射的。然而，据我所知，Linux内核使用的是从用户堆栈开始的高端内存。

问在32位机器中0x08048000之前的内存是用来做什么的？
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在32位机器中0x08048000之前的内存是用来做什么的？EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在32位机器中0x08048000之前的内存是用来做什么的？
EN