4 ms·
Very likely larger amounts of binary data linked in your program should better be "read only data", and hence be put in the ".rodata" section. From the objcopy
by cnvogel 11y ago
Very likely larger amounts of binary data linked in your program should better be "read only data", and hence be put in the ".rodata" section. From the objcopy manpage:
objcopy -I binary -O <output_format> -B <architecture> \
--rename-section .data=.rodata,alloc,load,readonly,data,contents \
<input_binary_file> <output_object_file>
I had made a short demo of this technique quite a few years ago, but regretably hadn't included the .rodata thing: https://github.com/vogelchr/objcopy_to_carray https://github.com/vogelchr/objcopy_to_carray, so if you want to check this out with minimal effort, have fun with it ;-).
[optiplex /home/chris/objcopy_to_carray (master)]
$ make
cc -Wall -Wextra -ggdb -Os -c -o testme.o testme.c
objcopy -I binary -O elf64-x86-64 -B i386:x86-64 \
--rename-section .data=.rodata,alloc,load,readonly,data,contents \
/etc/passwd passwd.o || (rm -f passwd.o ; exit 1)
cc testme.o passwd.o -o testme
[optiplex /home/chris/objcopy_to_carray (master)]
$ ./testme
Dumping /etc/passwd, in memory @0x4006a4, size is 1701.
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/bin/false
daemon:x:2:2:daemon:/sbin:/bin/false
mail:x:8:12:mail:/var/spool/mail:/bin/false
- twoodfin 11y agoI'll add that by segregating read-only and writeable data, you allow the virtual memory system to efficiently share a single copy of the read-only data among all processes loading it.
- cnvogel 11y agoYou are perfectly right. And there's also a second use-case: In some embedded applications things run directly from ROM/flash and things put in the .rodata-section will stay there and not get copied to RAM (which you obviously have to do for modifyable data).