This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Wed, Mar 03, 2010 at 11:29:29AM +0000, James Blackburn wrote:However the thing I'm still failing to see why the increment is the last section's vma/lma delta. Just like users have the expectation that unspecified VMAs follow on from the previous, shouldn't the same be true for the lma?
If you change the relative delta, and your runtime copies from LMA to VMA at startup, then it's going to copy the following section to the wrong place. The most likely scenario for this is with alignment. For instance, suppose there's normally 15 bytes of padding.
I'm a little confused. Before & after the patch, the vma hasn't changed. The patch simply moves the lma so that the sections are more tightly packed (as seems to be done currently with overlay sections). The code in ldlang.c should continue to correctly align the the lma to the section alignment. In the manual there's an example on laying out ROM sections: http://sourceware.org/binutils/docs-2.20/ld/Output-Section-LMA.html#Output-Section-LMA If more sections were added, following on from .mdata, the gap in the physical address space would be the same as the vma gap, rather than packing the data in the ROM section as might be desired (and is done explicitly for the first data section in the example).
Cheers, James
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |