Re: [gccsdk] Help Using Asasm

In message <mpro.mpkazw03e9si801p3.lists@stevefryatt.org.uk>
Steve Fryatt <lists@stevefryatt.org.uk> wrote:

> On 6 Jul, John Tytgat wrote in message
> <bd1a1f6753.Jo@hobbes.bass-software.com>:
>
> [Much useful stuff]
>
> > Hope this helps a bit
>
> It certainly does -- many thanks. A number of key gaps in my knowledge are
> now filled, although it also raises some more questions that I didn't know
> to ask before...
>
> One of the sources I'm trying to move across is the IcnClipBrd module, which
> came from ObjAsm code generated out of ARMalyser (as Thomas's original
> sources were lost, IIRC). That's obviously not going to want to end up in
> AIF format; I've had a dig around the GCCSDK sources, and having found the
> DRender module have come up with something like the following

The module case is indeed totally different. Good thinking to have a
look how it's done in DRenderer :-)

> --8<--
> AREA Module,CODE
> ENTRY
>
> ModuleHeader
> DCD StartCode
> DCD InitialisationCode
> DCD FinalisationCode
> DCD ServiceCallHandler offset
> DCD TitleString
> DCD HelpString
> DCD CommandTable table offset
> DCD 0
> DCD 0
> DCD 0
> DCD 0
> DCD 0
> DCD ModuleFlagWord
>
> ModuleFlagWord
> DCD 1
>
> ; etc...
>
> END
> --8<--
>
> Assembling this with
>
> $ asasm -o main.o main.s
> $ arm-unknown-riscos-strip -O binary -o hello_module,ffa main.o
>
> (as DRender's Makefile does) seems to come up with the desired result. I'm
> not sure if it's the "correct" way to do it, though -- it seems to be
> generating an ELF file and then stripping away the ELF bits?

Indeed, it's a bit brutal tbh but does do the job.

> The original code (which originally came from ARMalyser) opened with simply
>
> --8<--
> ORG &0
> ENTRY
> --8<--
>
> at the start which seems to cause AsAsm to generate unwanted code for
> constructs like
>
> --8<--
> LDR R1, TaskWord
>
> TaskWord
> DCD &4B534154
> --8<--
>
> (specifically MOV R1, &xxxx where &xxxx is the offset into the module of
> TaskWord, as opposed to PC-relative LDR R1, &xxxx which was intended).
> Reading the ObjAsm manual gives the the impression that this is what I
> should probably expect ORG 0 to do.

A module is in the first place a relocatable piece of code. So telling
the assmebler the next/current area is going to be assembled for
address 0 (or any other value) let him know for sure what {PC} value
actually will be and the freedom to exploit this. There are other cases
where this is going to happen, e.g. ADR(L) Rx, <label> can result in
MOV/MVN/MOVW/MOV32 (pseudo)instructions.

I would discourage the use of ORG 0 for module code. The DRenderer
approach is better but even there I would actually explicitely code
offsets as offsets, i.e. the subtracting the target label with a base
label. I'll fix that in DRenderer.

John.
--
John Tytgat, in his comfy chair at home
John.Tytgat@aaug.net

_______________________________________________
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