Re: A89: About saving integers in C.
[Prev][Next][Index][Thread]
Re: A89: About saving integers in C.
On Wed, Sep 20, 2000 at 07:52:45AM +0200, Zeljko Juric wrote:
>
> Are you able to fix Xavier's linker (it is open-source) instead of
> making your one, and to upgrade it to can do everything which your
> linker can do? I think that it is better idea than making independent
> linker. If you do so, you will become a member of TIGCC team (of
> course, if you want this)...
I can't (=refuse to) fix his linker because I consider it a miracle that it
works at all. I mean, how can it fail to handle uninitialized data when this
really works out automatically if you simply parse the object files
properly? Why does it only accept COFFs with exactly three sections? And why
does it assume that these sections are .text, .data and .bss, and in that
particular order? Why are 16 bit relocations not supported (bsr/bra/
"d16(pc)") -- they're both smaller and faster! Why .. etc...
It seems to me that I'd have to rewrite most or all of it from scratch.
But wait a minute -- I've already done that!
I can add support for kernel programs, libraries etc (and Prosit, if
requested) to mlink, because it is already aware of ROM calls, library calls
etc except that it still doesn't know how to put everything together into a
(kernel) program image.
What do you say?
> By the way, why "jmp _main" etc. make problems with your linker?
"jmp _main" by itself doesn't cause any problems -- but the assumption that
this instruction always appears at offset 0 in the program image is NOT TRUE
with mlink. (Tell me, what happens if you link a (nostub) C program with an
asm routine using Xavier's linker when you mention the asm object file
*first* on the command line: `link asmroutine.o nostub_c_program.o' ?)
/Johan "Knowledge is an illusion without answers."
References: