Tại sao kích thước arm-no-eabi báo cáo phần .data là 0 mặc dù tôi đang sử dụng RAM khởi tạo?

Question

Tôi hơi bối rối bởi kết quả tôi nhận được khi tôi sử dụng tiện ích kích thước của toolchain (Yagarto và codesourcery). nó đang báo cáo rằng tôi đang sử dụng 0 byte trong phần dữ liệu. xem dưới đây

$ arm-none-eabi-size.exe rest-server-example.crazy-horse.elf 
    text data  bss  dec  hex filename 
    79364  0 34288 113652 1bbf4 rest-server-example.crazy-horse.elf 

tôi biết mã của tôi đang sử dụng và khởi tạo biến RAM tĩnh để các giá trị khác hơn 0.

thú vị đủ khi tôi vượt qua công cụ kích thước trực tiếp một số các tập tin đối tượng đang nhận được liên kết tôi thấy phần .data được báo cáo

dụ:

text data  bss  dec  hex filename 
    1648  0  20 1668  684 obj_crazy-horse/uip-nd6.o 
    200  12 2652 2864  b30 obj_crazy-horse/uip-packetqueue.o 
    12  0  0  12  c obj_crazy-horse/uip-split.o 
    1816  24  48 1888  760 obj_crazy-horse/usb-core.o 
    284  0  0  284  11c obj_crazy-horse/usb-interrupt.o 
    2064  20  188 2272  8e0 obj_crazy-horse/xmac.o 

Tại sao các báo cáo tập tin elf 0 cho phần .data khi các tập tin đối tượng mà m ake nó đang báo cáo các giá trị khác không?

FYI Tôi đang làm việc trên phần mềm nhúng cho một AT91SAM7x256 Micro

chỉnh sửa:

thêm CFLAGS và LDFLAGS

CFLAGS += -O -DRUN_AS_SYSTEM -DROM_RUN -ffunction-sections 

LDFLAGS += -L $(CPU_DIRECTORY) -T $(LINKERSCRIPT) -nostartfiles -Wl,-Map,$(TARGET).map 

chỉnh sửa # 2: từ đối tượng bãi chúng ta có thể thấy rõ phần .data có dữ liệu được gán cho nó nhưng tiện ích kích thước không chọn nó vì một lý do nào đó objdump link

Tất cả những gì tôi đang tìm kiếm là sử dụng chính xác RAM của mình Tôi không cố gắng tìm hiểu xem một trong các biến của tôi đã được tối ưu hóa chưa.

chỉnh sửa 3: hơn thông tin cho thấy các tiện ích kích thước không nhìn thấy một cái gì đó trong phần .data

$ arm-none-eabi-size.exe -A -t -x rest-server-example.crazy-horse.elf 
rest-server-example.crazy-horse.elf : 
section    size  addr 
.vectrom    0x34 0x100000 
.text    0x10fc8 0x100038 
.rodata   0x149c 0x111000 
.ARM.extab   0x30 0x11249c 
.ARM.exidx   0xe0 0x1124cc 
.data    0x1028 0x200000 
.bss    0x7bec 0x201028 
.stack    0xa08 0x20f5f8 
.ARM.attributes  0x32  0x0 
.comment    0x11  0x0 
.debug_aranges  0xc68  0x0 
.debug_info  0x2b87e  0x0 
.debug_abbrev  0x960b  0x0 
.debug_line  0x9bcb  0x0 
.debug_frame  0x4918  0x0 
.debug_str   0x831d  0x0 
.debug_loc  0x13fad  0x0 
.debug_ranges  0x620  0x0 
Total    0x7c4c5 

Answer 1

giải thích của tôi sẽ là kịch bản mối liên kết tạo ra một phần có thể nạp được duy nhất, trong đó có chứa các giá trị ban đầu của phần dữ liệu và một đoạn mã khởi động sao chép dữ liệu vào phần dữ liệu chưa được khởi tạo. Điều này là cần thiết nếu bạn muốn có một tệp hình ảnh duy nhất có thể chạy từ bộ nhớ chỉ đọc, vì không có trình nạp ELF ở phía trước thì sẽ thực hiện bản sao đó cho bạn.

Thông thường, điều này chỉ được thực hiện trong phần để phân đoạn ánh xạ (tức là phần đầu ra được sắp xếp trong tập lệnh liên kết bằng lệnh vị trí phần >) thay vì lập bản đồ phần đầu vào hai lần, nhưng điều đó chắc chắn có thể .

Số lượng sử dụng khá chính xác: kích thước văn bản là lượng dung lượng Flash cần thiết, kích thước BSS là số lượng RAM cần thiết. Dữ liệu khởi tạo được tính hai lần, một lần cho dữ liệu ban đầu trong Flash và một lần cho dữ liệu có thể sửa đổi trong RAM.

Answer 2

Phần .data của bạn có thuộc tính CODE và điều này gây nhầm lẫn "arm-no-eabi-size". Kích thước của phần .data được thêm không chính xác vào tổng kích thước văn bản thay vì kích thước dữ liệu.

Tôi đoán là bạn có một số mã được lưu trữ trong flash nhưng được sao chép vào ram tại thời gian chạy như trình xử lý ngắt nhanh hoặc lập trình lại flash phải chạy từ RAM.Điều này sẽ đặt thuộc tính CODE cho phân đoạn dữ liệu và "kích thước" tin rằng tất cả .data là văn bản.