Hi, Ullrich von Bassewitz wrote: > Just add "define = yes" to the BSS segment in the linker config, and the > linker will export the symbols __BSS_RUN__, __BSS_LOAD__ and __BSS_SIZE__. I'm aware of that. But how could I tell the linker to start the INIT_CODE segment from __BSS_LOAD__ (or __BSS_RUN__, they're the same for my case)? This obviously doesn't work: MEMORY { ZP: start = $0080, size = $0040, type = rw; RAM: start = $0700, size = $B900, file = %O; RAM2: start = __BSS_LOAD__, size = $C000 - __BSS_LOAD__, file = +O; } SEGMENTS { CODE: load = RAM, type = ro; RODATA: load = RAM, type = ro; DATA: load = RAM, type = rw; BSS: load = RAM, type = bss, define = yes; INIT_CODE: load = RAM2, type = ro; INIT_RODATA: load = RAM2, type = ro; INIT_DATA: load = RAM2, type = rw; INIT_BSS: load = RAM2, type = bss; } Oliver Schmidt wrote: > Maybe you want to check out the Apple2 startup code: > > When loaded from disk the INIT segment is located where the BSS > segment "should be" - simply because there's one contiguous file that > is loaded. The startup code first moves INIT above BSS (making sure > that an overlap between original and final INIT region is okay). Then > the stuff in INIT is called (incl. clearing the BSS). Later on the > INIT segment gets (potentially) overwritten by the stack and/or heap. I don't need any stack or heap. I want the INIT_* segments overlaid with BSS, not only in the file but in the memory too. I clear BSS later, in the CODE segment. But thanks anyway, when reading your posts, it occured to me that I can pull this trick by calling ld65 once with a bogus RAM2 address and make it generate a map file. Now that I know where BSS is supposed to be, I can call it a second time, this time with a known RAM2 offset, using some perl magic. The only remaining problem is the fact that I stink at perl. Good opportunity to start fixing that :) Thanks, Fatih. ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo@musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.Received on Tue Nov 10 17:29:30 2009
This archive was generated by hypermail 2.1.8 : 2009-11-10 17:29:32 CET