[Bug ld/16127] NOLOAD section data contents inclusion in output file

[elbartoglm4 at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=16127

--- Comment #1 from Gael <elbartoglm4 at gmail dot com> ---
(In reply to Gael from comment #0)
> 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).

For information: a possible workaround is to set the output section as a DSECT
(dummy section), but as said in the documentation, this doesn't prevent an
other output section to map symbols at the same addresses.

-- 
You are receiving this mail because:
You are on the CC list for the bug.