Bug 16127 - NOLOAD section data contents inclusion in output file
Summary: NOLOAD section data contents inclusion in output file
Status: NEW
Alias: None
Product: binutils
Classification: Unclassified
Component: ld (show other bugs)
Version: 2.18
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-11-06 15:17 UTC by Gael
Modified: 2013-11-06 15:23 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gael 2013-11-06 15:17:36 UTC
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).
Comment 1 Gael 2013-11-06 15:21:39 UTC
(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.