[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug ld/12565] New: NOLOAD sections empty

From: jifl-bugzilla at jifvik dot org
Subject: [Bug ld/12565] New: NOLOAD sections empty
Date: Thu, 10 Mar 2011 17:56:35 +0000


           Summary: NOLOAD sections empty
           Product: binutils
           Version: 2.22 (HEAD)
            Status: NEW
          Severity: minor
          Priority: P2
         Component: ld
        AssignedTo: address@hidden
        ReportedBy: address@hidden

It appears that the fix for bug #5522 (fixed by H.J. Lu between 2.18 and 2.19
in Jan 2008) is not quite right.

When bringing over an existing linker script (which worked before 2.19), it
happened to mark the DWARF debug sections as NOLOAD, e.g.:

    .debug_info         0 (NOLOAD) : { *(.debug_info .gnu.linkonce.wi.*) }  \

The use of NOLOAD is redundant, but also shouldn't be an issue. However the fix
for bug #5522 causes the .debug_info section to be filled with 0's instead of
data. Analysis with readelf or objdump shows that it in other respects the
section has the correct flags and properties.

This is not a high priority for me personally as I can trivially just remove
the (NOLOAD), however someone who needs to use NOLOAD for contents that /would/
otherwise be loadable, may be surprised to find that the section is always
completely zeroed. This goes beyond what NOLOAD should be doing. If they didn't
want any part of the section in the image, they could just use /DISCARD/, so it
removes the point of NOLOAD.

I can confirm this problem still exists in CVS today 2011-03-10.

I expect you can see the problem on any platform by using a slightly modified
linker script, adding (NOLOAD) into the .debug_info line (this section just
makes it easy to demonstrate the problem). readelf -x .debug_info will either
show all 0s, or proper data.

Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]