On 15/09/15 11:27, Gavin Wraith wrote:
In message <55f7e5f4.1000...@sky.com>
Lee Noar <leen...@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
