CUtil Makefile

I’m having a go at making a Utility in C, and I’ve got a hello world, with this Makefile

COMPONENT      = TestUtil
INCLUDE_OSLIB ?= -IOS:
CINCLUDES      = ${INCLUDE_OSLIB}
LIBS           = ${OSLIB}
OBJS            = main

include CUtil

LDFLAGS        = -util

c.main

#include <stdio.h>
#include "os.h"

int main(int argc, char **argv)
{
  printf("Hello, world\n");
  return 0;
}

It links a utility, but when runs says “Trap in trap handler…”. I might be able to do without stdlib, so I tried getting rid of ANSILib by putting

UTIL_LIBS = ${OSLIB}

after the include CUtil, but it then fails to link saying symbol __main is undefined (I tried putting that as a function but then it says no entry point defined).

So:

Has someone got a working utility, in C, using CUtil or otherwise that links and runs ok with or without stdlib functions?

I wouldn’t think that the SharedCLibrary (or AnsiLib for that matter) expects that environment!

I don’t think we have any ready-to-go stubs / “crt0” to allow a “C-only” utility to be written. But, it shouldn’t be too hard to write some minimal stubs that will work with code that doesn’t need the standard library.

A (non-exhaustive) search of the sources turns up two uses of the CUtil makefile:

• SystemRes.LoadWimp (pure assembler)
• zinflate (C + asm stub)

zinflate is an unusual case – it’s the zlib decompression code used for compressed ROM images. So instead of producing a runnable Utility, it produces a position-independent binary which begins with the decompression header described here. But it does give some clues as to what’s necessary for creating an assembler stub that can be used with arbitrary C:

1. Make sure __RelocCode gets called. __RelocCode is a function emitted by the linker, so you also need to make sure the linker is emitting it – which I believe will require either LDFLAGS=-RMF or LDFLAGS=-util. More info here
2. Set up the arguments for the call to main (or whatever you want your main alternative to be). Since CUtil compiles the code as if it were an Absolute with stack limit checking/stack extension disabled, I don’t think there’s any need to set up FP, SL, or a stack chunk header (_kernel_stack_chunk).
3. Call main
4. Return to the OS

I wouldn’t think that the SharedCLibrary (or AnsiLib for that matter) expects that environment!

Yeah, you’d have trouble trying to convince either of those to work in a Utility.

Ok, here’s my working hello world.

s.entry

        IMPORT main
        IMPORT __RelocCode

        EXPORT __main

        AREA |Asm_Code|,CODE,READONLY
        ENTRY

__main
        STR   R14,[R13,#-4]!
        MOV   R11,#0
        BL    __RelocCode
        BL    main
        LDR   PC,[R13],#4

        END

c.main

#include "os.h"

int main(const char *name, const char *tail)
{
  xos_write0("Hello, world");
  xos_new_line();
  return 0;
}

Makefile

COMPONENT      = TestUtil
INCLUDE_OSLIB ?= -IOS:
CINCLUDES      = ${INCLUDE_OSLIB}
OBJS           = main entry

include CUtil

UTIL_LIBS = ${OSLIB}
LDFLAGS   = -util

I did zero FP for the benefit of the first stack frame. I didn’t try and pass through the R12 workspace yet, I’ll see how it goes as I write the program — I think the most sensible will be to just make everything local variables since it’s all coming out of that same 1K block anyway.

Thanks :-)

Note that __RelocCode corrupts R0-R3, R11 & R12.

I’ve had to abandon this idea as I need to start a new application which I’m not allowed to do from a utility, so I’m doing a runnable module instead. It’s nice to know that you can do it though.