Bug 24035 - wrong VMA when not specified explicitly
Summary: wrong VMA when not specified explicitly
Status: RESOLVED WONTFIX
Alias: None
Product: binutils
Classification: Unclassified
Component: ld (show other bugs)
Version: 2.31
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-12-25 21:05 UTC by Stas Sergeev
Modified: 2019-01-25 09:56 UTC (History)
1 user (show)

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


Attachments
test case (34.78 KB, application/gzip)
2018-12-25 21:05 UTC, Stas Sergeev
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stas Sergeev 2018-12-25 21:05:10 UTC
Created attachment 11493 [details]
test case

Attached is a test-case.
Please run test.sh.
It will link multiple objects (of freedos)
and look for a symbol address in the linker map.
This symbol is in the section .ibss, which VMA
is not specified in the linker script. The value
that linker takes, looks completely wrong. It was
reported that older linker (from ubuntu xenial) do
work properly in this case, just using the VMA after
the previous section, which is in this case .idata.
But newer linker seems to use the VMA of the section
.itext.
I already fixed the linker script, but I think this
behaviour change is a regression.
Comment 1 Alan Modra 2019-01-25 09:56:19 UTC
The 2.28 linker just happened to work due to the way orphan sections were handled there.  (You have quite a few sections not mentioned in your script and not covered by /DISCARD/:{*(.*)}, perhaps you meant to write /DISCARD/:{*(*)} without the dot?  If you do that, 2.28 doesn't work the way you expect either.)

The problem is that .idata is empty, and contains no symbol assigments.  That results in the section being discarded from the output and also not affecting ld's tracking of dot in the default memory region.

When you are creating what are effectively overlays, you need to be especially careful with vma assignments.