Re: [cc65] linking to o65

Hi,

On Thu, Jan 19, 2012 at 03:52:59PM +0100, Ullrich von Bassewitz wrote:
> 
> Hi!
> 
> On Thu, Jan 19, 2012 at 09:48:35AM +0100, Gábor Lénárt wrote:
> > * I want to link into o65 object format rather than a "ready-to-run" prg.
> > * I have some undefined symbol, which should be not a problem: the
> >   software which loads the o65 (as from external file, from disk, for
> >   example) would provide the missing information (common routines referenced
> >   by my programs would be implemented by the "loader")
> > * Can I set up some o65 specific header information (cpu type, alignment,
> >   object type, ? If not, it's maybe possible that I write an utility which
> >   "modifies" the o65 generated by cc65, but it's not so elegant anyway.
> >
> > It's not clear for me currently, how I should do this, can someone help?
> 
> ld65 is mostly tailored for generating o65 executables, not o65 object files.

Indeed, I used bad notion, I meant o65 executable (however from the point of
view of the format, the difference is not so big).

Thanks for the answer, I guess I start with the lunix target (of ld65), as
it seems ld65 generates o65 for that, so the situation can be somewhat
similar.

Btw, I am not really sure if it's sane what I want. If I compile a C program
with cc65 I can see references like these in the generated asm:

jsr     pushax
jsr     incax2
jsr     _printf

I would like not only _printf() call is implemented "by my own" but also
internal stuffs like pushax and incax2. I have the hope with this that
loaded programs (in o65 format) can be as small as possible, since the
described functionality is implemented by the "loader" and anyway they are
common in all code, so why would I store them again and agin in every
programs? Just for information: my ultimate goal is to write some "hobby OS"
by my own (for DTV, where there is enough RAM, relocatable stack/zero page,
etc, so a multitask OS can be implemented more easily than with a stock C64
for example), even with multitasking. The "loader stuff" is just the first
step to test some of my ideas, no multitask, and other similar features yet.

However, it's possible that it would be faster and more easy to implement
with fixed locations of pushax,incax,_printf etc in the loader code, so I
should not do the linking with many string comparation operations, but
providing eg "pushax" as a fixed address before running ld65. Then I would
use o65 format just for being relocatable code, so the program itself can be
loaded to any memory address which will be useful if there are more
concurent running tasks in the (far?) future.

What made me a bit unsure: how "stable" the "internal ABI/API"? I mean about
pushax, etc. Is it common to have a new function like this with a new cc65
version? Since if I implement those by my own, I will have problem with a
newer cc65 if it uses things differently, or new stuff is introduced etc.

> You didn't specify which type you're targeting. And, it is tested mostly with
> cc65 modules. So while there is some support for other output, it is rarely
> used and may therefore be untested/non working.

Well, if lunix target works well, it will be ok, I can create a
configuration similar to the lunix starting with the linker config file
dumped with ld65 (ld65 --dump-config lunix) and modified for my needs. I guess :)

> Regarding imports: Specifying the o65 imports in the linker config allows the
> linker to do error checking. Treating every unknown symbol as import might be
> possible but delays the error to the point where the executable is run.

That's true. However most OSes work this way, it's possible with eg Linux
that an ELF binary refeers for a symbol that dynamic linker cannot resolve
at the time when you want to execute it.

> There's also a reason not to rely on imports: The string table for the names
> of the symbols may get rather big. This is the reason why loadable drivers
> (which a in o65 format) use a jump table instead of imports by name.

That's an important point. Just I had the dream that there can be an OS
which has programs compatible with any computers which can run that OS and
use the same CPU, but the exact type of the computer is not important. By
providing fixed addresses instead of linkable stuffs (given by its names)
there is a stricter need, maybe an architecture can't provide for me too
well to place the OS code to the very same address I have it on another kind
of machine. In nutshell: I wanted to create something which is depends on
the CPU only, nothing more, if the CPU is compatible with 6502 (and the OS
is ported for that computer of course) it will run, no need a single bit of
modification.
 
> Header information (apart from 16/32 bit which is small/large in the config)
> can currently not be set. The functions are there, but there are no matching
> attributes in the config file.
> 
> So as a summary: The currently available features are probably not enough for
> what you want to do. Most of them can be easily added. But since o65 usage has
> been rare, I would prefer to add just the things that are really necessary.

I see. I would not use the .o format of cc65 directly as I guess it's not
designed for this purpose (maybe not so easy to handle on a pre-PC era based
system with limited resources, and also it's for internal use, as far as I
can guess it's not even always "stable" in the sense that the format can
change, while o65 is quite simple and has a well-defined structure by a
documentation. If I am wrong, execuse me).

- Gábor
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.