From: <bo...@co...> - 2007-09-22 09:01:25
|
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 |