This is the mail archive of the
mailing list for the binutils project.
RE: Confusion about value stored in linker script
- From: "Dave Korn" <dave dot korn at artimi dot com>
- To: "'Rick Mann'" <rmann at latencyzero dot com>, "'binutils'" <binutils at sourceware dot org>
- Date: Thu, 1 Nov 2007 19:08:24 -0000
- Subject: RE: Confusion about value stored in linker script
- References: <2FC8A28D-E3FF-4E69-9B0B-6106F00552C3@latencyzero.com>
On 01 November 2007 19:02, Rick Mann wrote:
> I do a lot of this kind of thing:
> . = 0x80008000
> .text :
> . = ALIGN(4);
> gVectorsStart = .;
> KEEP (obj/vectors.o(.text));
> gVectorsEnd = .;
> . = ALIGN(4);
> I expect gVectorsStart and gVectorsEnd to contain the value of the
> address at each point.
That's wrong. They don't *contain* the address; they *are* the address,
i.e. they are not variables, the compiler has not allocated some space in
memory and stored the value there. They are symbols; effectively, the address
of some variable or object in memory from the compiler's and assembler's
points of view.
> In C, I refer to them like this:
> typedef unsigned long UInt32;
> extern UInt32* gVectorsStart;
> extern UInt32* gVectorsEnd;
> However, when I look at the values in those variables from the C code,
> it seems like the value contained is the value at that point in the
> link. In other words, the first few bytes of vectors.o are 0xe59ff018,
> and that's what I see as the value of the gVectorsStart. I *expected*
> to see that for *gVectorsStart (the pointed-to data).
They aren't pointers and they aren't variables. They are just numbers. Try
this instead: tell the compiler that these are references to a single byte of
memory by pretending they are 'char' variables:
extern char gVectorsStart, gVectorsEnd;
Then take the address of those variables:
extern UInt32 *pgVectorsStart = &gVectorsStart;
extern UInt32 *pgVectorsEnd = &gVectorsEnd;
Can't think of a witty .sigline today....