Các biến tĩnh được lưu trữ trong C và C ++ ở đâu?

Trong phân đoạn nào (.BSS, .DATA, khác) của tệp thực thi là các biến tĩnh được lưu trữ để chúng không có xung đột tên? Ví dụ:

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);
}                              }

Nếu tôi biên dịch cả hai tệp và liên kết nó với một tệp chính gọi fooTest () và barTest nhiều lần, các câu lệnh printf sẽ tăng độc lập. Có ý nghĩa vì các biến foo và bar là cục bộ của đơn vị dịch.

Nhưng lưu trữ được phân bổ ở đâu?

Để rõ ràng, giả định là bạn có một chuỗi công cụ sẽ xuất ra một tệp ở định dạng ELF. Vì vậy, tôi tin rằng có có được một số không gian dành trong file thực thi cho các biến tĩnh.
Đối với mục đích thảo luận, giả sử chúng tôi sử dụng chuỗi công cụ GCC.

Số liệu thống kê của bạn đi đâu phụ thuộc vào việc chúng có được khởi tạo không . Dữ liệu tĩnh được khởi tạo bằng không đi vào .BSS (Khối bắt đầu bằng ký hiệu) , dữ liệu không khởi tạo bằng không đi vào .DATA

Khi một chương trình được tải vào bộ nhớ, nó được tổ chức thành các phân đoạn khác nhau. Một trong những phân khúc là phân khúc DATA . Phân đoạn dữ liệu được chia nhỏ thành hai phần:

Phân đoạn dữ liệu khởi tạo: Tất cả dữ liệu toàn cầu, tĩnh và không đổi được lưu trữ tại đây.
Phân đoạn dữ liệu chưa được khởi tạo (BSS): Tất cả các dữ liệu chưa được khởi tạo được lưu trữ trong phân khúc này.

Dưới đây là một sơ đồ để giải thích khái niệm này:

đây là liên kết rất tốt để giải thích các khái niệm này:

http://www.inf.udec.cl/~leo/teoX.pdf

Trong thực tế, một biến là tuple (lưu trữ, phạm vi, loại, địa chỉ, giá trị):

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

Phạm vi cục bộ có thể có nghĩa là cục bộ đối với đơn vị tịnh tiến (tệp nguồn), hàm hoặc khối tùy thuộc vào vị trí được xác định. Để hiển thị biến cho nhiều hơn một hàm, nó chắc chắn phải nằm trong vùng DATA hoặc BSS (tùy thuộc vào việc nó được khởi tạo rõ ràng hay không, tương ứng). Sau đó, phạm vi của nó phù hợp với tất cả (các) chức năng hoặc (các) chức năng trong tệp nguồn.

Vị trí lưu trữ của dữ liệu sẽ phụ thuộc vào việc thực hiện.

Tuy nhiên, ý nghĩa của tĩnh là "liên kết nội bộ". Do đó, biểu tượng là nội bộ của đơn vị biên dịch (foo.c, bar.c) và không thể được tham chiếu bên ngoài đơn vị biên dịch đó. Vì vậy, không thể có sự va chạm tên.

trong khu vực "toàn cầu và tĩnh" :)

Có một số vùng nhớ trong C ++:

• đống
• cửa hàng miễn phí
• cây rơm
• toàn cầu và tĩnh
• hăng sô

Xem ở đây để trả lời chi tiết cho câu hỏi của bạn:

Phần sau đây tóm tắt các vùng nhớ phân biệt chính của chương trình C ++. Lưu ý rằng một số tên (ví dụ: "heap") không xuất hiện như vậy trong dự thảo [tiêu chuẩn].

     Memory Area     Characteristics and Object Lifetimes
     --------------  ------------------------------------------------

     Const Data      The const data area stores string literals and
                     other data whose values are known at compile
                     time.  No objects of class type can exist in
                     this area.  All data in this area is available
                     during the entire lifetime of the program.

                     Further, all of this data is read-only, and the
                     results of trying to modify it are undefined.
                     This is in part because even the underlying
                     storage format is subject to arbitrary
                     optimization by the implementation.  For
                     example, a particular compiler may store string
                     literals in overlapping objects if it wants to.


     Stack           The stack stores automatic variables. Typically
                     allocation is much faster than for dynamic
                     storage (heap or free store) because a memory
                     allocation involves only pointer increment
                     rather than more complex management.  Objects
                     are constructed immediately after memory is
                     allocated and destroyed immediately before
                     memory is deallocated, so there is no
                     opportunity for programmers to directly
                     manipulate allocated but uninitialized stack
                     space (barring willful tampering using explicit
                     dtors and placement new).


     Free Store      The free store is one of the two dynamic memory
                     areas, allocated/freed by new/delete.  Object
                     lifetime can be less than the time the storage
                     is allocated; that is, free store objects can
                     have memory allocated without being immediately
                     initialized, and can be destroyed without the
                     memory being immediately deallocated.  During
                     the period when the storage is allocated but
                     outside the object's lifetime, the storage may
                     be accessed and manipulated through a void* but
                     none of the proto-object's nonstatic members or
                     member functions may be accessed, have their
                     addresses taken, or be otherwise manipulated.


     Heap            The heap is the other dynamic memory area,
                     allocated/freed by malloc/free and their
                     variants.  Note that while the default global
                     new and delete might be implemented in terms of
                     malloc and free by a particular compiler, the
                     heap is not the same as free store and memory
                     allocated in one area cannot be safely
                     deallocated in the other. Memory allocated from
                     the heap can be used for objects of class type
                     by placement-new construction and explicit
                     destruction.  If so used, the notes about free
                     store object lifetime apply similarly here.


     Global/Static   Global or static variables and objects have
                     their storage allocated at program startup, but
                     may not be initialized until after the program
                     has begun executing.  For instance, a static
                     variable in a function is initialized only the
                     first time program execution passes through its
                     definition.  The order of initialization of
                     global variables across translation units is not
                     defined, and special care is needed to manage
                     dependencies between global objects (including
                     class statics).  As always, uninitialized proto-
                     objects' storage may be accessed and manipulated
                     through a void* but no nonstatic members or
                     member functions may be used or referenced
                     outside the object's actual lifetime.

Tôi không tin sẽ có một vụ va chạm. Sử dụng tĩnh ở cấp độ tệp (các hàm bên ngoài) đánh dấu biến là cục bộ cho đơn vị biên dịch hiện tại (tệp). Nó không bao giờ hiển thị bên ngoài tệp hiện tại vì vậy không bao giờ phải có tên có thể được sử dụng bên ngoài.

Sử dụng tĩnh bên trong một hàm là khác nhau - biến chỉ hiển thị cho hàm (dù tĩnh hay không), giá trị của nó chỉ được giữ nguyên qua các lệnh gọi đến hàm đó.

Trong thực tế, tĩnh thực hiện hai điều khác nhau tùy thuộc vào vị trí của nó. Trong cả hai tuy nhiên trường hợp này, khả năng hiển thị biến được giới hạn trong một cách mà bạn có thể dễ dàng ngăn chặn đụng độ namespace khi liên kết.

Có nói rằng, tôi tin rằng nó sẽ được lưu trữ trong DATAphần này, có xu hướng có các biến được khởi tạo thành các giá trị khác không. Tất nhiên, đây là một chi tiết triển khai, không phải là thứ bắt buộc theo tiêu chuẩn - nó chỉ quan tâm đến hành vi, chứ không phải cách mọi thứ được thực hiện dưới vỏ bọc.

Làm thế nào để tìm thấy nó với objdump -Sr

Để thực sự hiểu những gì đang xảy ra, bạn phải hiểu di dời liên kết. Nếu bạn chưa bao giờ chạm vào điều đó, hãy xem xét việc đọc bài viết này trước .

Hãy phân tích một ví dụ ELF Linux x86-64 để tự mình xem nó:

#include <stdio.h>

int f() {
    static int i = 1;
    i++;
    return i;
}

int main() {
    printf("%d\n", f());
    printf("%d\n", f());
    return 0;
}

Biên dịch với:

gcc -ggdb -c main.c

Dịch ngược mã với:

objdump -Sr main.o

• -S dịch ngược mã với nguồn gốc xen kẽ
• -r hiển thị thông tin di dời

Bên trong sự dịch ngược của fchúng ta thấy:

 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

và .data-0x4nói rằng nó sẽ đi đến byte đầu tiên của .dataphân khúc.

Có -0x4bởi vì chúng tôi đang sử dụng địa chỉ tương đối RIP, do đó, %riptrong hướng dẫn và R_X86_64_PC32.

Điều này là bắt buộc vì RIP trỏ đến hướng dẫn sau , bắt đầu 4 byte sau 00 00 00 00đó là những gì sẽ được di dời. Tôi đã giải thích điều này chi tiết hơn tại: https://stackoverflow.com/a/30515926/895245

Sau đó, nếu chúng tôi sửa đổi nguồn thành i = 1và thực hiện phân tích tương tự, chúng tôi kết luận rằng:

• static int i = 0 tiếp tục .bss
• static int i = 1 tiếp tục .data

Đây là cách (dễ hiểu):

Nó phụ thuộc vào nền tảng và trình biên dịch mà bạn đang sử dụng. Một số trình biên dịch lưu trữ trực tiếp trong đoạn mã. Các biến tĩnh luôn chỉ có thể truy cập được đối với đơn vị dịch hiện tại và các tên không được xuất do đó các xung đột tên lý do không bao giờ xảy ra.

Dữ liệu được khai báo trong một đơn vị biên dịch sẽ đi vào .BSS hoặc .Data của đầu ra tệp đó. Dữ liệu ban đầu trong BSS, không được cung cấp trong DATA.

Sự khác biệt giữa dữ liệu tĩnh và toàn cầu xuất hiện trong việc bao gồm thông tin ký hiệu trong tệp. Trình biên dịch có xu hướng bao gồm thông tin biểu tượng nhưng chỉ đánh dấu thông tin toàn cầu như vậy.

Trình liên kết tôn trọng thông tin này. Thông tin ký hiệu cho các biến tĩnh được loại bỏ hoặc xử lý để các biến tĩnh vẫn có thể được tham chiếu theo một cách nào đó (với các tùy chọn gỡ lỗi hoặc ký hiệu). Trong cả hai trường hợp, các đơn vị biên dịch có thể bị ảnh hưởng vì trình liên kết giải quyết các tham chiếu cục bộ trước tiên.

Tôi đã thử nó với objdump và gdb, đây là kết quả tôi nhận được:

(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.

đây là kết quả 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

Vì vậy, có nghĩa là, bốn biến của bạn được đặt trong phần dữ liệu cùng tên, nhưng có độ lệch khác nhau.

biến tĩnh được lưu trữ trong phân đoạn dữ liệu hoặc phân đoạn mã như đã đề cập trước đó.
Bạn có thể chắc chắn rằng nó sẽ không được phân bổ trên stack hoặc heap.
Không có rủi ro xung đột vì statictừ khóa xác định phạm vi của biến là tệp hoặc hàm, trong trường hợp va chạm, có trình biên dịch / liên kết để cảnh báo bạn về.
Một ví dụ điển hình

Chà, câu hỏi này hơi cũ, nhưng vì không ai chỉ ra bất kỳ thông tin hữu ích nào: Kiểm tra bài đăng bằng 'mohit12379' giải thích việc lưu trữ các biến tĩnh có cùng tên trong bảng ký hiệu: http://www.geekinterview.com/question_details/ 24745

Câu trả lời rất có thể phụ thuộc vào trình biên dịch, vì vậy bạn có thể muốn chỉnh sửa câu hỏi của mình (ý tôi là, ngay cả khái niệm phân đoạn cũng không bắt buộc bởi ISO C hay ISO C ++). Chẳng hạn, trên Windows, một tệp thực thi không mang tên biểu tượng. Một 'foo' sẽ được bù 0x100, còn lại có lẽ là 0x2B0 và mã từ cả hai đơn vị dịch được biên dịch khi biết các giá trị bù cho "foo" của họ.

cả hai sẽ được lưu trữ độc lập, tuy nhiên nếu bạn muốn làm rõ cho các nhà phát triển khác, bạn có thể muốn gói chúng trong các không gian tên.

bạn đã biết hoặc nó lưu trữ trong bss (khối bắt đầu bằng ký hiệu) cũng được gọi là phân đoạn dữ liệu chưa được khởi tạo hoặc trong phân đoạn dữ liệu khởi tạo.

hãy lấy một ví dụ đơn giản

void main(void)
{
static int i;
}

biến tĩnh ở trên không được khởi tạo, vì vậy nó đi đến phân đoạn dữ liệu chưa được khởi tạo (bss).

void main(void)
{
static int i=10;
}

và tất nhiên nó được khởi tạo bởi 10 vì vậy nó đi đến phân đoạn dữ liệu được khởi tạo.