On Tuesday 02 November 2010, Agent Friday wrote: > On Mon, Nov 1, 2010 at 7:39 PM, Groepaz <groepaz@gmx.net> wrote: > So, I see in source\libsrc\c64\crt0.s that the BASIC stub is placed > in segment "EXEHDR", but I don't see anything in the way you invoke > ld65 or anything in the .cfg file that would cause that segment to > be linked. I don't understand what you mean here. In the config it's defined that the `EXEHDR` segment belongs to the `HEADER` memory region which states it goes to the output file. So if you link anything that has bytes going to the `EXEHDR` segment, those will appear in the linked binary. > Perhaps the "one symbol is referenced" rule means is > forcing the entire crt0 module to be linked; but in my recent > experience, putting code into a segment that is not listed in the > SEGMENTS statement of the config file normally causes an error (or > at least a warning) when I try to build/link it. But this is not > what we see when compiling for a C64 target. But `EXEHDR` *is* listed in the `SEGMENTS` of the c64 config. So there is no error or warning if you link in objects which put bytes there. You get a warning if you *don't* put data in defined `SEGMENT`\s which are not defined as optional though:: $ ld65 --target c64 test.o test2.o ld65: Warning: [builtin config](10): Segment `EXEHDR' does not exist ld65: Warning: [builtin config](11): Segment `STARTUP' does not exist ld65: Warning: [builtin config](17): Segment `ZPSAVE' does not exist Unresolved external `__STARTUP__' referenced in: test.s(12) Unresolved external `_printf' referenced in: test.s(13) … This is because I have not given the `crt0.o` to link. ``ld65`` does not magically link this or any other runtime stuff as you see with the last error in the output above. You have to give all used object files or the runtime library explicitly to the linker:: $ ld65 --target c64 test.o test2.o c64.lib `crt0.o` is part of `c64.lib`, so there is really no magic here. > So I'm left to guess that the linker is performing some amount of > hidden "magic" to make it work, although I don't see why it couldn't > just as well be accomplished explicitly. For example, if I wanted > to replicate this behavior on my own "target", would it be sufficient > to place an "EXEHDR" entry (or other name I've chosen for the stub) > as the the first item in the segments clause? > > Which leads me to the next question... Are the segments linked into > the final binary in the same order they are listed in the .cfg file? > I wonder how the "EXEHDR", or even the "STARTUP" segment, is trusted > to always appear as the very first thing in the file. Segments are put into their memory region in the order they are defined. So this determines the order within a memory region. What comes first in a file depends on the definition order of the memory regions. Ciao, Marc 'BlackJack' Rintsch -- “Wenn man aber nur noch eine Meinungsfreiheit zulassen will, die geschmacklose, unbequeme und für einzelne schmerzhafte Inhalte nicht umfasst, sollte man fairerweise nicht mehr von Meinungsfreiheit sprechen. Von Demokratie vielleicht auch nicht mehr.” Udo Vetter, lawblog.de ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo@musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.
This archive was generated by hypermail 2.1.8 : 2010-11-02 12:29:13 CET