问题标签 [memory-layout]

我刚刚了解了函数指针（指向存储函数机器代码的地址的指针）。这让我想到了机器代码以及它是如何存储在内存中的。

机器代码是否连续存储在内存中，以便可以“手动”增加指针，直到它指向下一个/上一个函数？

这是调试器的作用吗？他让我“看到”程序计数器在机器代码中指向的位置？

结论：可以用函数指针编程原始调试器吗？

我理解对了吗，还是我走错了路？

我确定这个问题之前已经被问过很多次了，所以我快速搜索并找到了这个解释浮点值结构的维基百科页面。

我正在通过包含一些浮点值（对于游戏）的网络发送和接收数据，这导致我提出以下问题：

1. 我需要担心字节顺序吗？
2. 如果字节顺序很重要，我如何在不进行强制转换*(float*)或联合的情况下提取这些值？（例如整数位移的技巧）

提前致谢。

我知道菱形继承会导致歧义，可以通过使用继承来避免virtual Base Classes，问题不在于它。当类是多态的时，问题是关于菱形层次结构中最派生类的大小。这是示例代码和示例输出：

我得到的输出是：

据我了解Base，它包含一个虚拟成员函数，因此
在此环境中 sizeof Base = vptr 的大小 = 4

类似的是案例Derived1和Derived2课程。

这是我与上述场景相关的问题：类对象
的大小如何Derived3，这是否意味着 Derived3 类有 2 个 vptr？
该类如何Derived3与这 2 个 vptr 一起工作，关于它使用的机制有什么想法吗？
类的大小保留为编译器的实现细节而不由标准定义（因为虚拟机制本身是编译器的实现细节）？

这可能是一个重复的问题。我想知道windows进程的内存映射是什么样的？我正在寻找细节。请提供博客、文章和其他相关文献的链接。

为什么当我在 gdb 中调试 asm 源是 0x8048080 时，为代码的起始入口点选择的地址？这只是相对偏移量，而不是指令内存的实际偏移量，对吗？

我说的是英特尔 32 位平台。Linux 内核版本 2.6.31-14。

输出：

在上面的代码中，我有以下困惑。为什么代码位于0x8048484而不是靠近虚拟内存开头的某个地方，例如，0x00000400？据我所知，布局应该是这样的：

内存不足..................................................HighMemory

所以，文本不应该在记忆中太远。它应该靠近较低的内存，不是吗？

我编写了几个程序，发现当以 64 位编译时，内存映射段（例如共享对象和共享内存所在的位置）总是位于 7f9aca84a000-7fff88400000 附近的某个位置，但从不完全相同。

我想知道在 x86_64 架构（ELF64）上这个内存段是否有固定的起始地址，或者这个段的最大和最小范围是多少？

这就是我问这个问题的原因。我们正在将系统从 Tru64 UNIX 迁移到 Linux。该系统使用IPC Sys V共享内存的复杂固定内存映射，并使用链表在该段内从结构到另一个结构。由于这段代码的大小和复杂性，以及我们手头有限的时间，我们正试图找到一种可靠的方法来修复共享内存的开始（有效地使用带有指定地址的 shmat 来附加段）。使用 64 位，虚拟地址空间是如此巨大（48 位有效可能的地址），以至于选择“安全”固定地址比 32 位更容易且风险更小。

OpenGL 具有BufferData(int array[])where arraymust be format等功能x-y-z x-y-z ...。

它只是一个整数序列，其中每个连续的 3 元组都被解释为一个顶点。

将其表示为 std::vector 是否安全，其中顶点声明为：

在我看来，这将使在语义上更清楚正在发生的事情。但是，是否有可能保证这会奏效？

如果不是，是否有任何其他方式来提供数据的更多语义表示？

跟进为什么ELF执行入口点虚拟地址的形式是0x80xxxxxx而不是零0x0？为什么 Linux 二进制文件的虚拟内存地址从 0x8048000 开始？，为什么我不能ld使用与默认值不同的入口点ld -e？

如果我这样做，我会得到一个segmentation fault返回码 139 的结果，即使是默认入口点附近的地址也是如此。为什么？

编辑：

我会让问题更具体：

如果我编译as program.s -o program.o它然后用静态链接它ld -N program.o -o program，readelf -l program显示0x0000000000400078为VirtAddr文本段的和0x400078作为入口点。运行时，会打印“Hello world”。

但是，当我尝试链接ld -N -e0x400082 -Ttext=0x400082 program.o -o program（将文本段和入口点移动 4 个字节）时，程序将是killed. 现在检查它会readelf -l显示两个不同的类型标题LOAD，一个 at0x0000000000400082和一个 at 0x00000000004000b0。

当我尝试0x400086时，一切正常，而且只有一个LOAD部分。

1. 这里发生了什么？
2. 我可以选择哪些内存地址，哪些不能选择，为什么？

谢谢。

所以我在玩 Olly 调试器，嗅探我能找到的关于 windows 的信息，然后按下 M 按钮，它弹出了那个内存映射窗口。所以我在谷歌上搜索了一些关于这个主题的文章，我发现我实际上可以写到我试过的 64K 以上的地址，而且很好。为什么它不起作用。关于那些较低的 2GB 空间：

• 为什么会有这些差距？例如，有 0x10000-0x1FFFF R/Wable 空间，然后没有 128K，然后是一些可读空间。我的意思是这已经被正确分页了，所以过去是否有像物理空间这样的东西并不重要（更不用说 0x20000-0x40000 应该完全可以读/写），为什么有人会决定不如此随意地使用一些地址空间？很可能我只是感到困惑，因为在来自 olly 调试器的内存映射中，很多行在列显示“包含”的地方都是空白的。是否有一些参考我可以从 olly 中针对这个内存映射，找出哪些空间有什么用途，因此是这样还是不是这样分页？

• 假设我真的不会搞砸关于内存管理的任何事情，使用较低的内存而不是使用堆为 Windows 编写程序是否可以，或者我会遇到一些问题吗？

感谢您阅读这个问题。

编辑

啊，我们在这里使用 0x10000 的内容，这也可能是该页面可写的原因。