Confusion about value stored in linker script

[Dave Korn]

On 01 November 2007 19:02, Rick Mann wrote:

> I do a lot of this kind of thing:
> 
> 	. = 0x80008000
> 	.text :
> 	{
> 		obj/start.o(.text);
> 		src/Interrupts.o(.text);
> 
> 		. = ALIGN(4);
> 		gVectorsStart = .;
> 		KEEP (obj/vectors.o(.text));
> 		gVectorsEnd = .;
> 
> 		. = ALIGN(4);
> 		*(.text);
> 	}
> 
> 
> 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;

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....