DDT debug - Cummings and Goings

That’s correct. C and assembly both use Text.

Zap will use the appropriate mode if the assembler is in a ‘s’ directory (also if called filename/s but I can’t remember if I set that myself).

So it is relying on Zap to colour text files.

Any chance of a separate file type?

If a program gives a list of procedures errors how do you read it back?

I don’t think a separate file type is needed, it’s up to text editors to decide how they syntax colour textual information.

Errors are delivered to the editor via the throwback mechanism.

When a ‘C’ module claims app memory – where is it mapped in?

App memory? C modules created with the DDE use their WimpSlot don’t they, like regular apps. Paged and all.

You can tell this by looking in TaskManager to see if it’s listed as an Application task or a Module task.
Alternatively, get it to spit the address of the memory claim to an error box or your debug logging of choice. Then you’ll know for certain.

When adding ARM code to ‘C’ module programs how do you add to the relocated list at the end of the code automatically – when the prog is linked together?

Do you have the DDE? Look at the examples and the user guides. Or look at DeskLib.

Briefly, in the assembler you EXPORT a function. It must obey APCS rules. In the C program, you define the function as extern <returntype> function_name(<parameters>) (as you would for a function in another module) and then you just call it as if it were any regular function.
As to how to paste all the bits together, that’s what the linker is for. Make an object file from the assembler source and just give it to the linker as you would the C object files. It will work out all the links – kind of it’s raison d’être…

Just fired up !Librarian – with DDE User Guide loaded.

Page 251
Talks about adding relocate values after ‘END’

DCD Rel_pointer01
DCD Rel_pointer02
DCD -1

And letting the linker/ASM sort things out.

[Edit]
No – that doesn’t seem to be it :-(

Hmm
Perhaps there is a Area
command that surrounds the relocated address – to tell the Linker/ASM to add then to the total relocated addresses at the end of the assembled module.

What’s this RO 5.29 13 May 2021 -

Debugger 2.07 16 May 2020

&E2444E0A
Sub r4,r4,#&0A,28

??

The constant being subtracted is &A0 = &A ROR 28. The 28 comes from the &E multiplied by two, &rxx on the end gives #&xx, ROR 2r.

Debugger shows #&0A,28 to indicate that it is a non-standard encoding of the constant, since it could have been produced using zero rotation as

&E24440A0 SUB r4, r4, #&A0

There’s some previous discussion of this here.

Debugger shows #&0A,28 to indicate that it is a non-standard encoding of the constant,

I had to use that notation in ARMalyser’s assembler output too, as the non standard encoding is quite common, and its required so you can reassemble back to exactly the same binary, despite not being very readable.

Thanks for this update.

Have come across some ‘C’ modules that Druck’s prog doesn’t finish at the end – grafting the output of !Sid gets around it.

Try to get exact copies of a redone module to start with – ADR’s can be different – using !Zap gets used to update them.

Have come across a ‘C’ module that doesn’t call the CLib SWI – Mmm perhaps it’s Stub doesn’t need the 32bit version.

!Arm_Debug is very handy to step through modules 26 only at the moment.

Surprised !DDT couldn’t handle modules – seems to handle SVC code Ok.

Did try putting one of DDT SWIs in a module – got so far at starting DDT at the right place in the module – but it wouldn’t single step from there :-(

Perhaps Gerf could comment!

Colin, please send me examples of anything that doesn’t work with ARMalyser, and I’ll have a go at fixing it.

Tks – do I have an your current address?

Regarding ARMalyser, I remember some years ago while trying to figure out an elusive compiler bug that I tried to compare the disassembly of 2 versions of object files: one version compiled with what was at the time the latest ROOL version and one with a pre-ROOL version. IIRC the disassembly of addresses (or was it the associated comments?) differed between the two versions which made SideDiff’s job harder.

To me it seemed that the ROOL compiler added extra flags in the descriptors of these addresses which made ARMalyser a little bit wary in their handling.