In what segment (.BSS, .DATA, other) of an executable file are static variables stored so that they don't have name collision? For example:
段(。可执行文件的BSS、.DATA、其他)是存储的静态变量,因此它们没有名称冲突?例如:
foo.c: bar.c:
static int foo = 1; static int foo = 10;
void fooTest() { void barTest() {
static int bar = 2; static int bar = 20;
foo++; foo++;
bar++; bar++;
printf("%d,%d", foo, bar); printf("%d, %d", foo, bar);
} }
If I compile both files and link it to a main that calls fooTest() and barTest repeatedly, the printf statements increment independently. Makes sense since the foo and bar variables are local to the translation unit.
如果我编译两个文件并将其链接到一个调用fooTest()和barTest的main,那么printf语句就会独立地增加。这是有意义的,因为foo和bar变量是翻译单元的本地变量。
But where is the storage allocated?
但是存储在哪里?
To be clear, the assumption is that you have a toolchain that would output a file in ELF format. Thus, I believe that there has to be some space reserved in the executable file for those static variables.
For discussion purposes, lets assume we use the GCC toolchain.
需要说明的是,假设您有一个工具链,它将以ELF格式输出文件。因此,我认为必须在可执行文件中为那些静态变量预留一些空间。为了讨论的目的,让我们假设我们使用GCC工具链。
16 个解决方案
#1
113
Where your statics go depends on if they are 0 initialized or not. 0 initialized static data goes in .BSS (Block Started by Symbol), non 0 initialized data goes in .DATA
静态的位置取决于它们是否为0初始化。初始化静态数据进入。bss(由符号开始的块),未初始化的数据进入。data
#2
89
When a program is loaded into memory, it’s organized into different segments. One of the segment is DATA segment. The Data segment is further sub-divided into two parts:
Initialized data segment: All the global, static and constant data are stored here.
Uninitialized data segment(BSS): All the uninitialized data are stored in this segment.
当一个程序被加载到内存中时,它被组织成不同的段。其中一段是数据段。数据段进一步细分为两个部分:初始化数据段:在这里存储所有全局数据、静态数据和常量数据。未初始化数据段(BSS):所有未初始化的数据都存储在这个段中。
Here is a diagram to explain this concept:
这里有一个图表来解释这个概念:
here is very good link explaining these concepts:
这里有很好的链接来解释这些概念:
http://www.inf.udec.cl/~leo/teoX.pdf
http://www.inf.udec.cl/ ~狮子座/ teoX.pdf
#3
27
In fact, a variable is tuple (storage, scope, type, address, value):
事实上,变量是元组(存储、范围、类型、地址、值):
storage : where is it stored, for example data, stack, heap...
scope : who can see us, for example global, local...
type : what is our type, for example int, int*...
address : where are we located
value : what is our value
Local scope could mean local to either the translational unit (source file), the function or the block depending on where its defined. To make variable visible to more than one function, it definitely has to be in either DATA or the BSS area (depending on whether its initialized explicitly or not, respectively). Its then scoped accordingly to either all function(s) or function(s) within source file.
局部作用域可以指翻译单元(源文件)、函数或块的局部,这取决于它的定义。要使变量对多个函数可见,它肯定必须位于数据或BSS区域(具体取决于它是否显式地初始化)。然后它相应地作用域到源文件中的所有函数或函数。
#4
20
The storage location of the data will be implementation dependent.
数据的存储位置将依赖于实现。
However, the meaning of static is "internal linkage". Thus, the symbol is internal to the compilation unit (foo.c, bar.c) and cannot be referenced outside that compilation unit. So, there can be no name collisions.
然而,静态的含义是“内部链接”。因此,符号是编译单元(foo)的内部。c, bar.c),不能在编译单元之外引用。因此,不可能有名称冲突。
#5
11
I don't believe there will be a collision. Using static at the file level (outside functions) marks the variable as local to the current compilation unit (file). It's never visible outside the current file so never has to have a name.
我不相信会发生碰撞。在文件级别使用static(外部函数)将变量标记为当前编译单元(文件)的本地变量。它在当前文件之外是不可见的,所以永远不用名称。
Using static inside a function is different - the variable is only visible to the function, it's just its value is preserved across calls to that function.
在函数内部使用静态变量是不同的——变量只对函数可见,它的值在对函数的调用中被保留。
In effect, static does two different things depending on where it is. In oth cases however, it limits the visibility of the variable to prevent namespace *es,
实际上,根据静态的位置,它可以做两件不同的事情。然而,在实际上,它限制了变量的可见性,以防止名称空间冲突,
Having said that, I believe it would be stored in DATA which tends to have initialized variable. The BSS originally stood for byte-set-<something> which held variables which weren't initialized.
话虽如此,我相信它将存储在具有初始化变量的数据中。BSS最初是为字节集而设的——
#6
7
How to find it yourself with objdump -Sr
如何用objdump -Sr找到它
To actually understand what is going on, you must understand linker relocation. If you've never touched that, consider reading this post first.
要真正了解发生了什么,您必须了解链接器重新定位。如果你从来没有接触过这篇文章,可以考虑先看看这篇文章。
Let's analyze a Linux x86-64 ELF example to see it ourselves:
让我们来分析一个Linux x86-64 ELF示例,看看它自己:
#include <stdio.h>
int f() {
static int i = 1;
i++;
return i;
}
int main() {
printf("%d\n", f());
printf("%d\n", f());
return 0;
}
Compile with:
编译:
gcc -ggdb -c main.c
Decompile the code with:
反编译的代码:
objdump -Sr main.o
-
-S
decompiles the code with the original source intermingled - -S将代码与原始源代码混合
-
-r
shows relocation information - - r显示搬迁信息
Inside the decompilation of f
we see:
在f的分解过程中我们看到:
static int i = 1;
i++;
4: 8b 05 00 00 00 00 mov 0x0(%rip),%eax # a <f+0xa>
6: R_X86_64_PC32 .data-0x4
and the .data-0x4
says that it will go to the first byte of the .data
segment.
而.data-0x4表示它将到达。data段的第一个字节。
The -0x4
is there because we are using RIP relative addressing, thus the %rip
in the instruction and R_X86_64_PC32
.
这里的-0x4是因为我们使用的是RIP相对寻址,也就是指令中的% RIP和R_X86_64_PC32。
It is required because RIP points to the following instruction, which starts 4 bytes after 00 00 00 00
which is what will get relocated. I have explained this in more detail at: https://*.com/a/30515926/895245
这是必需的,因为RIP指向下面的指令,在00 00 00后开始4个字节,这就是要重新定位的。我已经详细说明了这一点:https://*.com/a/30515926/895245。
Then, if we modify the source to i = 1
and do the same analysis, we conclude that:
然后,如果我们将源修改为i = 1并进行同样的分析,我们得到:
-
static int i = 0
goes on.bss
- 静态int i = 0在。bss上
-
static int i = 1
goes on.data
- 静态int i = 1进入。data
#7
6
It depends on the platform and compiler that you're using. Some compilers store directly in the code segment. Static variables are always only accessible to the current translation unit and the names are not exported thus the reason name collisions never occur.
这取决于您使用的平台和编译器。有些编译器直接存储在代码段中。静态变量总是只能访问当前的转换单元,并且不会导出名称,因此不会发生名称冲突。
#8
5
Data declared in a compilation unit will go into the .BSS or the .Data of that files output. Initialised data in BSS, uninitalised in DATA.
在编译单元中声明的数据将进入该文件输出的. bss或.Data中。在BSS中初始化数据,在数据中未初始化。
The difference between static and global data comes in the inclusion of symbol information in the file. Compilers tend to include the symbol information but only mark the global information as such.
静态和全局数据的区别在于文件中包含符号信息。编译器倾向于包含符号信息,但只标记全局信息。
The linker respects this information. The symbol information for the static variables is either discarded or mangled so that static variables can still be referenced in some way (with debug or symbol options). In neither case can the compilation units gets affected as the linker resolves local references first.
链接器尊重这个信息。静态变量的符号信息要么被丢弃,要么被破坏,这样静态变量仍然可以以某种方式被引用(使用调试或符号选项)。在这两种情况下,当链接器首先解析本地引用时,编译单元都不会受到影响。
#9
4
in the "global and static" area :)
在“全球和静态”领域:
there are several memory area in C++
c++中有几个内存区域
- heap
- 堆
- free store
- 免费存储
- stack
- 堆栈
- global & static
- 全局和静态
- const
- 常量
see here for detailed answer to your question
你的问题的详细答案见这里
#10
2
static variable stored in data segment or code segment as mentioned before.
You can be sure that it will not be allocated on stack or heap.
There is no risk for collision since static
keyword define the scope of the variable to be a file or function, in case of collision there is a compiler/linker to warn you about.
A nice example
如前所述,静态变量存储在数据段或代码段中。您可以确保它不会被分配到堆栈或堆上。由于静态关键字将变量的范围定义为文件或函数,因此没有发生冲突的风险,在发生冲突时,有一个编译器/链接器警告您。一个很好的例子
#11
2
Well this question is bit too old, but since nobody points out any useful information: Check the post by 'mohit12379' explaining the store of static variables with same name in the symbol table: http://www.geekinterview.com/question_details/24745
这个问题有点过时了,但是由于没有人指出任何有用的信息:请查看mohit12379解释符号表中相同名称的静态变量的存储:http://www.geekinterview.com/question_details/24745
#12
2
I tried it with objdump and gdb, here is the result what I get:
我尝试了objdump和gdb,得到的结果是:
(gdb) disas fooTest
Dump of assembler code for function fooTest:
0x000000000040052d <+0>: push %rbp
0x000000000040052e <+1>: mov %rsp,%rbp
0x0000000000400531 <+4>: mov 0x200b09(%rip),%eax # 0x601040 <foo>
0x0000000000400537 <+10>: add $0x1,%eax
0x000000000040053a <+13>: mov %eax,0x200b00(%rip) # 0x601040 <foo>
0x0000000000400540 <+19>: mov 0x200afe(%rip),%eax # 0x601044 <bar.2180>
0x0000000000400546 <+25>: add $0x1,%eax
0x0000000000400549 <+28>: mov %eax,0x200af5(%rip) # 0x601044 <bar.2180>
0x000000000040054f <+34>: mov 0x200aef(%rip),%edx # 0x601044 <bar.2180>
0x0000000000400555 <+40>: mov 0x200ae5(%rip),%eax # 0x601040 <foo>
0x000000000040055b <+46>: mov %eax,%esi
0x000000000040055d <+48>: mov $0x400654,%edi
0x0000000000400562 <+53>: mov $0x0,%eax
0x0000000000400567 <+58>: callq 0x400410 <printf@plt>
0x000000000040056c <+63>: pop %rbp
0x000000000040056d <+64>: retq
End of assembler dump.
(gdb) disas barTest
Dump of assembler code for function barTest:
0x000000000040056e <+0>: push %rbp
0x000000000040056f <+1>: mov %rsp,%rbp
0x0000000000400572 <+4>: mov 0x200ad0(%rip),%eax # 0x601048 <foo>
0x0000000000400578 <+10>: add $0x1,%eax
0x000000000040057b <+13>: mov %eax,0x200ac7(%rip) # 0x601048 <foo>
0x0000000000400581 <+19>: mov 0x200ac5(%rip),%eax # 0x60104c <bar.2180>
0x0000000000400587 <+25>: add $0x1,%eax
0x000000000040058a <+28>: mov %eax,0x200abc(%rip) # 0x60104c <bar.2180>
0x0000000000400590 <+34>: mov 0x200ab6(%rip),%edx # 0x60104c <bar.2180>
0x0000000000400596 <+40>: mov 0x200aac(%rip),%eax # 0x601048 <foo>
0x000000000040059c <+46>: mov %eax,%esi
0x000000000040059e <+48>: mov $0x40065c,%edi
0x00000000004005a3 <+53>: mov $0x0,%eax
0x00000000004005a8 <+58>: callq 0x400410 <printf@plt>
0x00000000004005ad <+63>: pop %rbp
0x00000000004005ae <+64>: retq
End of assembler dump.
here is the objdump result
这是objdump的结果
Disassembly of section .data:
0000000000601030 <__data_start>:
...
0000000000601038 <__dso_handle>:
...
0000000000601040 <foo>:
601040: 01 00 add %eax,(%rax)
...
0000000000601044 <bar.2180>:
601044: 02 00 add (%rax),%al
...
0000000000601048 <foo>:
601048: 0a 00 or (%rax),%al
...
000000000060104c <bar.2180>:
60104c: 14 00 adc $0x0,%al
So, that's to say, your four variables are located in data section event the the same name, but with different offset.
也就是说,你的四个变量在data section事件中,名称相同,但是偏移量不同。
#13
1
The answer might very well depend on the compiler, so you probably want to edit your question (I mean, even the notion of segments is not mandated by ISO C nor ISO C++). For instance, on Windows an executable doesn't carry symbol names. One 'foo' would be offset 0x100, the other perhaps 0x2B0, and code from both translation units is compiled knowing the offsets for "their" foo.
答案可能非常依赖于编译器,所以您可能想要编辑您的问题(我的意思是,即使是片段的概念也不是由ISO C或ISO c++所授权的)。例如,在Windows上,一个可执行文件不带有符号名。一个'foo'将被偏移0x100,另一个可能是0x2B0,两个翻译单元的代码在知道“他们的”foo的偏移量的情况下被编译。
#14
0
they're both going to be stored independently, however if you want to make it clear to other developers you might want to wrap them up in namespaces.
它们都是独立存储的,但是如果您想让其他开发人员更清楚地了解它们,您可能需要将它们封装在名称空间中。
#16
-1
you already know either it store in bss(block start by symbol) also referred as uninitialized data segment or in initialized data segment.
您已经知道,它可以存储在bss(按符号块开始)中,也可以称为未初始化的数据段,也可以存储在初始化的数据段中。
lets take an simple example
让我们举一个简单的例子
void main(void)
{
static int i;
}
the above static variable is not initialized , so it goes to uninitialized data segment(bss).
上面的静态变量没有初始化,所以它会进入未初始化的数据段(bss)。
void main(void)
{
static int i=10;
}
and of course it initialized by 10 so it goes to initialized data segment.
当然它是由10初始化的所以它会去初始化数据段。
#1
113
Where your statics go depends on if they are 0 initialized or not. 0 initialized static data goes in .BSS (Block Started by Symbol), non 0 initialized data goes in .DATA
静态的位置取决于它们是否为0初始化。初始化静态数据进入。bss(由符号开始的块),未初始化的数据进入。data
#2
89
When a program is loaded into memory, it’s organized into different segments. One of the segment is DATA segment. The Data segment is further sub-divided into two parts:
Initialized data segment: All the global, static and constant data are stored here.
Uninitialized data segment(BSS): All the uninitialized data are stored in this segment.
当一个程序被加载到内存中时,它被组织成不同的段。其中一段是数据段。数据段进一步细分为两个部分:初始化数据段:在这里存储所有全局数据、静态数据和常量数据。未初始化数据段(BSS):所有未初始化的数据都存储在这个段中。
Here is a diagram to explain this concept:
这里有一个图表来解释这个概念:
here is very good link explaining these concepts:
这里有很好的链接来解释这些概念:
http://www.inf.udec.cl/~leo/teoX.pdf
http://www.inf.udec.cl/ ~狮子座/ teoX.pdf
#3
27
In fact, a variable is tuple (storage, scope, type, address, value):
事实上,变量是元组(存储、范围、类型、地址、值):
storage : where is it stored, for example data, stack, heap...
scope : who can see us, for example global, local...
type : what is our type, for example int, int*...
address : where are we located
value : what is our value
Local scope could mean local to either the translational unit (source file), the function or the block depending on where its defined. To make variable visible to more than one function, it definitely has to be in either DATA or the BSS area (depending on whether its initialized explicitly or not, respectively). Its then scoped accordingly to either all function(s) or function(s) within source file.
局部作用域可以指翻译单元(源文件)、函数或块的局部,这取决于它的定义。要使变量对多个函数可见,它肯定必须位于数据或BSS区域(具体取决于它是否显式地初始化)。然后它相应地作用域到源文件中的所有函数或函数。
#4
20
The storage location of the data will be implementation dependent.
数据的存储位置将依赖于实现。
However, the meaning of static is "internal linkage". Thus, the symbol is internal to the compilation unit (foo.c, bar.c) and cannot be referenced outside that compilation unit. So, there can be no name collisions.
然而,静态的含义是“内部链接”。因此,符号是编译单元(foo)的内部。c, bar.c),不能在编译单元之外引用。因此,不可能有名称冲突。
#5
11
I don't believe there will be a collision. Using static at the file level (outside functions) marks the variable as local to the current compilation unit (file). It's never visible outside the current file so never has to have a name.
我不相信会发生碰撞。在文件级别使用static(外部函数)将变量标记为当前编译单元(文件)的本地变量。它在当前文件之外是不可见的,所以永远不用名称。
Using static inside a function is different - the variable is only visible to the function, it's just its value is preserved across calls to that function.
在函数内部使用静态变量是不同的——变量只对函数可见,它的值在对函数的调用中被保留。
In effect, static does two different things depending on where it is. In oth cases however, it limits the visibility of the variable to prevent namespace *es,
实际上,根据静态的位置,它可以做两件不同的事情。然而,在实际上,它限制了变量的可见性,以防止名称空间冲突,
Having said that, I believe it would be stored in DATA which tends to have initialized variable. The BSS originally stood for byte-set-<something> which held variables which weren't initialized.
话虽如此,我相信它将存储在具有初始化变量的数据中。BSS最初是为字节集而设的——
#6
7
How to find it yourself with objdump -Sr
如何用objdump -Sr找到它
To actually understand what is going on, you must understand linker relocation. If you've never touched that, consider reading this post first.
要真正了解发生了什么,您必须了解链接器重新定位。如果你从来没有接触过这篇文章,可以考虑先看看这篇文章。
Let's analyze a Linux x86-64 ELF example to see it ourselves:
让我们来分析一个Linux x86-64 ELF示例,看看它自己:
#include <stdio.h>
int f() {
static int i = 1;
i++;
return i;
}
int main() {
printf("%d\n", f());
printf("%d\n", f());
return 0;
}
Compile with:
编译:
gcc -ggdb -c main.c
Decompile the code with:
反编译的代码:
objdump -Sr main.o
-
-S
decompiles the code with the original source intermingled - -S将代码与原始源代码混合
-
-r
shows relocation information - - r显示搬迁信息
Inside the decompilation of f
we see:
在f的分解过程中我们看到:
static int i = 1;
i++;
4: 8b 05 00 00 00 00 mov 0x0(%rip),%eax # a <f+0xa>
6: R_X86_64_PC32 .data-0x4
and the .data-0x4
says that it will go to the first byte of the .data
segment.
而.data-0x4表示它将到达。data段的第一个字节。
The -0x4
is there because we are using RIP relative addressing, thus the %rip
in the instruction and R_X86_64_PC32
.
这里的-0x4是因为我们使用的是RIP相对寻址,也就是指令中的% RIP和R_X86_64_PC32。
It is required because RIP points to the following instruction, which starts 4 bytes after 00 00 00 00
which is what will get relocated. I have explained this in more detail at: https://*.com/a/30515926/895245
这是必需的,因为RIP指向下面的指令,在00 00 00后开始4个字节,这就是要重新定位的。我已经详细说明了这一点:https://*.com/a/30515926/895245。
Then, if we modify the source to i = 1
and do the same analysis, we conclude that:
然后,如果我们将源修改为i = 1并进行同样的分析,我们得到:
-
static int i = 0
goes on.bss
- 静态int i = 0在。bss上
-
static int i = 1
goes on.data
- 静态int i = 1进入。data
#7
6
It depends on the platform and compiler that you're using. Some compilers store directly in the code segment. Static variables are always only accessible to the current translation unit and the names are not exported thus the reason name collisions never occur.
这取决于您使用的平台和编译器。有些编译器直接存储在代码段中。静态变量总是只能访问当前的转换单元,并且不会导出名称,因此不会发生名称冲突。
#8
5
Data declared in a compilation unit will go into the .BSS or the .Data of that files output. Initialised data in BSS, uninitalised in DATA.
在编译单元中声明的数据将进入该文件输出的. bss或.Data中。在BSS中初始化数据,在数据中未初始化。
The difference between static and global data comes in the inclusion of symbol information in the file. Compilers tend to include the symbol information but only mark the global information as such.
静态和全局数据的区别在于文件中包含符号信息。编译器倾向于包含符号信息,但只标记全局信息。
The linker respects this information. The symbol information for the static variables is either discarded or mangled so that static variables can still be referenced in some way (with debug or symbol options). In neither case can the compilation units gets affected as the linker resolves local references first.
链接器尊重这个信息。静态变量的符号信息要么被丢弃,要么被破坏,这样静态变量仍然可以以某种方式被引用(使用调试或符号选项)。在这两种情况下,当链接器首先解析本地引用时,编译单元都不会受到影响。
#9
4
in the "global and static" area :)
在“全球和静态”领域:
there are several memory area in C++
c++中有几个内存区域
- heap
- 堆
- free store
- 免费存储
- stack
- 堆栈
- global & static
- 全局和静态
- const
- 常量
see here for detailed answer to your question
你的问题的详细答案见这里
#10
2
static variable stored in data segment or code segment as mentioned before.
You can be sure that it will not be allocated on stack or heap.
There is no risk for collision since static
keyword define the scope of the variable to be a file or function, in case of collision there is a compiler/linker to warn you about.
A nice example
如前所述,静态变量存储在数据段或代码段中。您可以确保它不会被分配到堆栈或堆上。由于静态关键字将变量的范围定义为文件或函数,因此没有发生冲突的风险,在发生冲突时,有一个编译器/链接器警告您。一个很好的例子
#11
2
Well this question is bit too old, but since nobody points out any useful information: Check the post by 'mohit12379' explaining the store of static variables with same name in the symbol table: http://www.geekinterview.com/question_details/24745
这个问题有点过时了,但是由于没有人指出任何有用的信息:请查看mohit12379解释符号表中相同名称的静态变量的存储:http://www.geekinterview.com/question_details/24745
#12
2
I tried it with objdump and gdb, here is the result what I get:
我尝试了objdump和gdb,得到的结果是:
(gdb) disas fooTest
Dump of assembler code for function fooTest:
0x000000000040052d <+0>: push %rbp
0x000000000040052e <+1>: mov %rsp,%rbp
0x0000000000400531 <+4>: mov 0x200b09(%rip),%eax # 0x601040 <foo>
0x0000000000400537 <+10>: add $0x1,%eax
0x000000000040053a <+13>: mov %eax,0x200b00(%rip) # 0x601040 <foo>
0x0000000000400540 <+19>: mov 0x200afe(%rip),%eax # 0x601044 <bar.2180>
0x0000000000400546 <+25>: add $0x1,%eax
0x0000000000400549 <+28>: mov %eax,0x200af5(%rip) # 0x601044 <bar.2180>
0x000000000040054f <+34>: mov 0x200aef(%rip),%edx # 0x601044 <bar.2180>
0x0000000000400555 <+40>: mov 0x200ae5(%rip),%eax # 0x601040 <foo>
0x000000000040055b <+46>: mov %eax,%esi
0x000000000040055d <+48>: mov $0x400654,%edi
0x0000000000400562 <+53>: mov $0x0,%eax
0x0000000000400567 <+58>: callq 0x400410 <printf@plt>
0x000000000040056c <+63>: pop %rbp
0x000000000040056d <+64>: retq
End of assembler dump.
(gdb) disas barTest
Dump of assembler code for function barTest:
0x000000000040056e <+0>: push %rbp
0x000000000040056f <+1>: mov %rsp,%rbp
0x0000000000400572 <+4>: mov 0x200ad0(%rip),%eax # 0x601048 <foo>
0x0000000000400578 <+10>: add $0x1,%eax
0x000000000040057b <+13>: mov %eax,0x200ac7(%rip) # 0x601048 <foo>
0x0000000000400581 <+19>: mov 0x200ac5(%rip),%eax # 0x60104c <bar.2180>
0x0000000000400587 <+25>: add $0x1,%eax
0x000000000040058a <+28>: mov %eax,0x200abc(%rip) # 0x60104c <bar.2180>
0x0000000000400590 <+34>: mov 0x200ab6(%rip),%edx # 0x60104c <bar.2180>
0x0000000000400596 <+40>: mov 0x200aac(%rip),%eax # 0x601048 <foo>
0x000000000040059c <+46>: mov %eax,%esi
0x000000000040059e <+48>: mov $0x40065c,%edi
0x00000000004005a3 <+53>: mov $0x0,%eax
0x00000000004005a8 <+58>: callq 0x400410 <printf@plt>
0x00000000004005ad <+63>: pop %rbp
0x00000000004005ae <+64>: retq
End of assembler dump.
here is the objdump result
这是objdump的结果
Disassembly of section .data:
0000000000601030 <__data_start>:
...
0000000000601038 <__dso_handle>:
...
0000000000601040 <foo>:
601040: 01 00 add %eax,(%rax)
...
0000000000601044 <bar.2180>:
601044: 02 00 add (%rax),%al
...
0000000000601048 <foo>:
601048: 0a 00 or (%rax),%al
...
000000000060104c <bar.2180>:
60104c: 14 00 adc $0x0,%al
So, that's to say, your four variables are located in data section event the the same name, but with different offset.
也就是说,你的四个变量在data section事件中,名称相同,但是偏移量不同。
#13
1
The answer might very well depend on the compiler, so you probably want to edit your question (I mean, even the notion of segments is not mandated by ISO C nor ISO C++). For instance, on Windows an executable doesn't carry symbol names. One 'foo' would be offset 0x100, the other perhaps 0x2B0, and code from both translation units is compiled knowing the offsets for "their" foo.
答案可能非常依赖于编译器,所以您可能想要编辑您的问题(我的意思是,即使是片段的概念也不是由ISO C或ISO c++所授权的)。例如,在Windows上,一个可执行文件不带有符号名。一个'foo'将被偏移0x100,另一个可能是0x2B0,两个翻译单元的代码在知道“他们的”foo的偏移量的情况下被编译。
#14
0
they're both going to be stored independently, however if you want to make it clear to other developers you might want to wrap them up in namespaces.
它们都是独立存储的,但是如果您想让其他开发人员更清楚地了解它们,您可能需要将它们封装在名称空间中。
#15
#16
-1
you already know either it store in bss(block start by symbol) also referred as uninitialized data segment or in initialized data segment.
您已经知道,它可以存储在bss(按符号块开始)中,也可以称为未初始化的数据段,也可以存储在初始化的数据段中。
lets take an simple example
让我们举一个简单的例子
void main(void)
{
static int i;
}
the above static variable is not initialized , so it goes to uninitialized data segment(bss).
上面的静态变量没有初始化,所以它会进入未初始化的数据段(bss)。
void main(void)
{
static int i=10;
}
and of course it initialized by 10 so it goes to initialized data segment.
当然它是由10初始化的所以它会去初始化数据段。