I figured out what I was doing wrong!  I was putting my example.o file (with main() in it)
first in my link command.  When I put crt0.o first, and example.o second, _GSINIT
landed in the code section!!!  :-)

The sdcc manual, in section 3.1.3 says:  
    "The file containing the main() function MUST be the FIRST file specified ...."
Apparently, this is not always true.

I assume the linker must be putting the sections in the order it first encounters
them, and with example.o linked first, it uses the order they appear in that file,
which is not the right order.  (why not?????  Couldn't the compiler put the
dummy .area's in main, or in all the object files, for that matter???)

With crt0.o first, it works fine (except that the linked file is now "crt0.ihx").  

If I use "-o example" to name the file, for some strange reason I don't get a .map file.  
Another odd thing is that when example.o is linked first, I can use
"-o example.hex", but with crt0.o first, it ignores the ".hex" and names the
output file "example.ihx".

What is the recommended way to link in a custom crt0.o?  Should I
explicitly list it as an object file to be linked?  Should I put it in my
own library?  Or should I overwrite the standard crt0.o in
SDCC\lib\z80???

I tried making my own library with my crt0.o in it, but when I use it,
_GSINIT goes back into data section!

Is there any reason to keep the standard crt0.o???

Also, I made a custom putchar.o in my library, but I got an error regarding
two definitions of _putchar.  I had to delete the putchar function from the
standard lib.  I thought that the manual said it would use the first one it found.  

Perhaps I am needlessly making trouble for myself by trying to put these into
a library, since it *does* all work if I link them in explicitly.  I just wonder
how others are doing this.

Thanks!!!
Randy