This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: ld - no diagnostic when the location counter moves backwards
- From: Nick Clifton <nickc at redhat dot com>
- To: Ron McCall <ronald dot mccall at snet dot net>
- Cc: binutils at sourceware dot org
- Date: Tue, 08 Aug 2006 14:42:49 +0100
- Subject: Re: ld - no diagnostic when the location counter moves backwards
- References: <20060725214105.70794.qmail@web80329.mail.yahoo.com>
Hi Ron,
The final assignment in foo.ld moves the location
counter backwards (see foo.map) but I get no error
from ld. Making just about any change to foo.ld makes
the error message appear (or the backward movement go
away). The ld manual, section 3.10.4 "The Location
Counter" states that the location counter may never be
moved backwards.
Is this a bug?
Well yes and no. Yes it is according to a strict interpretation of the
documentation, but essentially the documentation is wrong, or rather, it
is mis-worded. What it should say is "The location counter should not
be moved backwards. If it is, and the new, lower value is used to place
an object into the memory map, then an error will occur".
For example the linker will happily accept a backwards movement of the
location counter if it is then followed by a forwards movement that
moves it back to, or beyond where it used to be:
. = . - 4 ;
. = . + 4 ;
What is illegal is if the value of . is used to place an object into
memory after the location counter has been moved backwards:
. = . - 4;
PROVIDE (foo = .) ; /* This is OK. */
.foo : { LONG (0); } /* This is NOT OK. */
. = . + 4;
> We have a large program in which many different object
> file sections are placed into various fixed size
> memory regions and I want to be sure that the linker
> will tell me when I overflow one of these regions.
I think that you can be sure of this.
Cheers
Nick