Re: [gccsdk] no main

On 15/09/15 11:27, Gavin Wraith wrote:
> In message <55F7E5F4.1000002@sky.com>
> Lee Noar <leenoar@sky.com> wrote:
>
>> Does the interpreter reference these two symbols directly rather than
>> via dlsym?
>>
>> Lee.
>
> No - absolutely not. Nor should dlsym.

Ok.

> When a pack of object files are linked I would expect that the internal references
> are resolved,

Yes.

> and any other references are taken to be external,

Yes.

> and hence to be put into a table in the resulting elf output for later resolution.

Yes, dynamic relocations.

> Is that how gcc is supposed to function?

That sounds about right.

> Or does gcc need extra information
> about which symbols are to be considered local and which global?

There are symbols tables that the compiler/assembler generates that aid
in static linking (ie, at build time). Some symbols may end up not being
visible at all if they're local to a single object file, eg, a static
global variable.

> In my mind's eye I have a picture of a labelled directed graph, the vertices being
> object files, the arrows being labelled by symbols, referenced in the source
> vertex and exported within the target vertex. Is that a sensible picture?
> Any symbol not referenced from within the graph has to be external, and
> anything that is has to be internal.

Erm, TBH, I'm finding that hard to picture :-)

> I think sys.s has only one symbol not referenced by riscoslib.c - I might as
> well delete it. No symbols in sys.s are referenced by anything outside sys.s
> except from riscoslib.c. In particular sys.s makes no references to
> anything in liblua or the C libraries. It imports nothing.
> Am I right in thinking that I can write assembler directly into C source
> with GCC? That might simplify these linkage problems.

Yes, GCC's inline assembly is quite comprehensive.

> There are very few lines of it - especially in relation to the trouble they
> seem to be causing ;). There is no other way of giving RiscLua access to
> RISC OS SWIs, of course. Using the Norcroft compiler I had to use Objasm
> but perhaps GCC offers more flexible alternatives?

You can also call SWIs in C using either _kernel_swi, eg:

#include <kernel.h>
#include <swi.h>

...

_kernel_swi_regs r;
_kernel_oserror *err;

r.r[0] = 10;
r.r[1] = (int)"ram:$.test";
r.r[2] = 0xfff; /* file type */
r.r[4] = (int)start_addr;
r.r[5] = (int)end_addr;
err = _kernel_swi(XOS_Bit | OS_File, &r, &r);

or using _swix, eg:

_swix(OS_File, _IN(0)|_IN(1)|_IN(2)|_IN(4)|_IN(5),
10, "ram:$.test", 0xfff, start_addr, end_addr);

Completely off the top of my head and untested of course. The
first is probably easier to read and understand than the
second. Both are error prone due to weak type checking, but
that can be improved by wrapping them up as a function.

Lee.


_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK