http://sourceware.org/bugzilla/show_bug.cgi?id=16127
Bug ID: 16127
Summary: NOLOAD section data contents inclusion in output file
Product: binutils
Version: 2.18
Status: NEW
Severity: critical
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: elbartoglm4 at gmail dot com
Hi,
I am reporting something I consider incorrect in LD v2.18 regarding the
documentation about the "NOLOAD" section attribute. I tested this on LD v2.17
but I didn't notice the problem I found with v2.18.
In the linker command file, I define (among other sections) an output section
in which I put uninitialized data input sections and one initialized data input
section at the end. For information, the initialized data input section
contains only zeros, and its size is 0x720.
I define this output section as "NOLOAD" because I only want this memory
allocated and the symbols mapped in the memory region I specify, but I don't
want the contents of any of the input sections to be loaded in the output file
(.elf in my case).
But in my output file, I can find the zeros of the initialized data input
section in an other section where resides code: a hole of zeros with a size of
0x720 is present in the middle of it.
I checked the addresses and the ELF sections offsets and my assumptions seem
correct:
in the ELF file section headers dump, I can see the ELF sections offsets:
.NOLOAD_SECTION: ELF_offset = 0x0000F3C0
.CODE_SECTION; ELF_offset = 0x00010000
In the ELF file, the zeros are found at 0x00011640, which is an offset of
0x2280 from the NOLOAD_SECTION ELF_Offset. This offset corresponds to the
offset between the Virtual Memory Address (VMA) of the NOLOAD_SECTION beginning
(0x0180f3c0) and the first initialized data input section symbol VMA
(0x01811640).
To summarize: I assume LD puts the contents of the input sections (data or
code) in the output file even if the output section is set to NOLOAD (and we
see it only ALLOCATABLE when we dump the ELF file).
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
