extern variables defined in linked command file

Matt Shira said:

how does the compiler actually treat P2SEL in the .cmd file?

The linker creates a symbol named P2SEL and assigns it the value 0x002E.  Unlike other variables, no memory is reserved for it.  Since the location (a memory mapped register, I think) is supplied by the hardware, reserving memory is not necessary.

Matt Shira said:

And would it be regarded as a constant definition, an ordinary variable of type unsigned char, or an address or pointer?

The rest of the compiler tools regard P2SEL as a variable of type unsigned char.

Thanks and regards,

-George

No, the symbol P2SEL does not behave as a pointer, it behaves as what is technically called an "lvalue", i.e. an addressable data object.

I use the C6000 family instead fo what you're using, but the principle is the same:  The compiler has built-in knowledge about certain machine registers, and in effect "predefines" them to have the right properies.  On the C6x, for example, the command/status register is accessible using the symbol "CSR", which acts as though it has been predeclared as: extern cregister unsigned volatile CSR;  The linker doesn't need to see a matching external symbol definition, because the compiler translates any access using that symbol to a "move to/from control register" instruction with the target register hard=coded into the instruction.  In some other cases, "peripheral" device registers might be declared in chip-support library headers along the lines #define P2SEL (*(unsigned *)0x123456) (or whatever), where again when an access is made using that symbol, the compiler coverts it to a "move to/from indirect" with the hard-coded constant (0x123456) for the indirect address, so again the linker doesn't know about the symbol.

The external (linkable) symbol P2SEL is given the value 0x002E by the linker command file, which logically is an address and not the object itself (which in this case isn't allocated any storage by the linker).  The linker deals mainly with addresses, so when there is a reference from your C code to an external object using the name "P2SEL", the linker produces object code that refers to an object at the address 0x002E.  The linker does not see C or assembly-language code, nor final executable instructions and data; what it sees is a collection of partially completed executable code and data, along with special "relocation information" which the linker uses to complete the code by inserting the final run-time addresses of code and data objects.  (On some platforms, part of this linkage is done later, when the program is loaded into memory ready for execution.)  Names obtained from relocation information or otherwise handled by the linker always refer to addresses, even though the source code did not explicitly use a pointer value.

This can at times be puzzling.  I recently had to use the following code to access the linker-defined symbol _STACK_SIZE in a C6000 program that I wrote to probe the environment: "extern unsigned far _STACK_SIZE;" and "printf("Stack size is %u bytes.\n", (unsigned)&_STACK_SIZE);", which seems peculiar but is consistent with what was going on with P2SEL in your case.  If you think about it and understand how the linker's "__STACK_SIZE=4096" results in this code printing "Stack size is 4096 bytes." then you will probably have attained the desired state of enlightenment.  (Don't worry about the extra leading underscore; it's really the same symbol, just spelled differently between C source code and the external object code.  Some implementations do that and some don't.)