no arguments from Getenv

I have a file assembled with gnu as and it doesn’t get arguments , only the executable from OS_GetEnv.
But only after installing latest libs from pacman. On my RPCemu/RISC OS Direct it works just fine.
I have a very simple test case if someone is interested.

Hey Michael,

I have a file assembled with gnu as and it doesn’t get arguments , only the executable from OS_GetEnv.

That doesn’t work with GAS, it’s because of the ELFLoader, so not sure if it will ever work.

To retrieve CLI arguments in GNU AS you need to use the same technique we use on ARM Linux, in other words use r0 for argc and r1 for argv.

Alternatively, you can use RISC OS traditional way (OS_GetEnv etc.), but to make it work you must transform your ELF into an executable AIF with elf2aif. In this case things will work as usual.

BTW I have a video almost done specifically on retrieving command line parameters using GNU ASM, work is very busy at the moment, so I hadn’t much time to finish it (and I already have other videos to complete the editing anyway).

HTH

That doesn’t work with GAS, it’s because of the ELFLoader, so not sure if it will ever work.

Works in RPCemu with whatever version of elfloader that in included in RO Direct.

To retrieve CLI arguments in GNU AS you need to use the same technique we use on ARM Linux, in other words use r0 for argc and r1 for argv.

I got the impression , with the project I am playing with, is that arguments is on the stack. (in linux)

it’s because of the ELFLoader

How does ELFloader manage to screw up the environment string? Isn’t it supposed to be read only (unless explicitly set with OS_SetEnv)?

I have found the same. Argument that show on RPCEmu do not appear on the Titanium. The relevant environments look very similar.

Titanium

*FX0
RISC OS 5.29 (23 Jul 2023)
*
*test hello bye
ADFS::ROOL.$.Work.Proj.New-t.getenv.args.test*
*

RPCEmu

*fx0
RISC OS 5.29 (04 May 2023)
*
*test hello bye
HostFS::HostFS.$.SymLinks.uHD4.Internet.NFS.TiWork.getenv.test hello bye*
*

Both have the same module versions :-

*help sharedunixlibrary
==> Help on keyword SharedUnixLibrary
Module is: SharedUnixLibrary       1.16 (3 Apr 2020) (C) UnixLib Developers, 2001-2020
*help SOManager
==> Help on keyword SOManager
Module is: Shared Object Manager   3.04 (24 Dec 2021) (c) GCCSDK Developers
*help ARMEABISupport
==> Help on keyword ARMEABISupport
Module is: ARMEABISupport  1.05 (19 Jun 2023) (c) GCCSDK Developers

Nightmare!!

Why is it only the Titanium that loses the trailing arguments, there is no such issue on the RPi1 or RPi400 where the full environment string is shown. The issue also goes away on the unbooted Titanium with System and SharedLibs explicitly seen. Something on the Titanium is messing this up!

@ Michael

Works in RPCemu with whatever version of elfloader that in included in RO Direct.

That is why I normally test my code on every board (and if it’s code that needs to run on multiple RISC OS releases also on multiple old Acorn systems).

@ David

Thanks for sharing this, last night I was fried and had no energy to fire up some equipment and collect the different output from them all.

As an extra test, if you now use elf2aif for your test program, you’ll see it works fine on every system, so the only think I could think of is the ELFLoader, but had no time to figure out specifically what’s happening.

Something on the Titanium is messing this up!

I have seen it also on other devices, let me re-run all the tests (fun way to spend a Sunday afternoon! XD )

After a reboot all the arguments are now shown on the Titanium.

I got the impression , with the project I am playing with, is that arguments is on the stack. (in linux)

Yes, sorry I meant the same technique. On linux you have the addresses in sp, on RO they seems to be stored in r0 and r1:

On Linux you’d do something like:

main:                                   
    push {fp,lr}                        
    ldr  r8, =argc                      @ This to store argc in .data section
    str  sp, [r8]
    ldr  r8, =argv                      @ This to store argv in .data section
    add  fp,sp,#8                       @ fp <- start address
    str  fp,[r8]                        @ stores argv in .data section
...
    ldr  r5, =argv
    add  r5,r5,#4                       @ first parameter address 
...

While on RO you’d do the same (just different registers pointing at the args):

main:                                   
    push {fp,lr}                        
    ldr  r8, =argc                      @ This to store argc addr in .data section
    str  r0, [r8]
    ldr  r8, =argv                      @ This to store argv addr in .data section
    str  r1, [r8]
...
    ldr  r5, =argv
    add  r5,r5,#4                       @ first parameter address 
...

After a reboot all the arguments are now shown on the Titanium.

Interesting, so what are we loading that messes it up????

@ David

Found it!!!!

It seems related to GCC, if we load GCC then it stops working.

If we don’t then it works fine. (That BTW includes RPCEmu, if you load GCC on RPCEmu then it’ll stop working on RPCEmu as well)

if we load GCC then it stops working

Well spotted! Double clicking on GCC on both the Titanium and RPCemu stops it.

It’s the DDEUtils module!

It’s the DDEUtils module!

What on earth is GCC/SOM/whatever doing that would cause this to happen?

It’s the DDEUtils module!

Boom! Confirmed, it’s DDEUtils messing up with the ElfLoader somehow.

push {fp,lr}

@Paolo .. in thumb mode? :)

@ Michael

in thumb mode? :)

Hahah , sort of, more in “hurry mode” XD

A test case is here

It comprises Michael’s source., and a build of it, plus Obey files to do the build, run a test and to load and kill the DDEUtils module.

It’s being done intentionally.

/* If the DDEUtils module is loaded, then we use that for the arguments and
     just pass the ELF file name to the OS.  */

https://www.riscos.info/websvn/filedetails.php?repname=gccsdk&path=%2Ftrunk%2Fgcc4%2Friscos%2Fsoloader%2Fmodule2%2Fsom_runcom.c near the end…

This is a side effect of using GCC which outputs ELFs. The loader will be bashing things into a form that C programs like, so you’d either need to convert the ELF to an AIF so it runs directly, or start faffing around with DDEUtils like C programs do.

Don’t know exactly how GCC programs do it, but here’s how DDE stuff does: https://gitlab.riscosopen.org/RiscOS/Sources/Lib/RISC_OSLib/-/blob/master/kernel/s/k_body#L342

At a brief look, it seems as if GCC is doing it strangely.

It appears as if CLib is copying out the original command line (GetEnv), and if there’s an extended command line available via DDEUtils, to replace the command line with the longer DDEUtils one, but if there’s no extended command line then use the GetEnv one.

GCC on the other hand, appears to be defaulting to using DDEUtils if it is present, and thus nuking the GetEnv command line in the process. I suppose it makes sense if the environment is set up as “always use this if it’s there”, and that’s where your problem lies.

While on RO you’d do the same (just different registers pointing at the args):

Can’t get that to work. Can you give a working example (very simple, smallest possible)?

Can’t get that to work. Can you give a working example (very simple, smallest possible)?

Of course:

.file    "args"

.global main

.equ    XOS_Exit,   0x20011

.text

.func main
main:
        push {r0-r8, ip, lr}
        @ Save the registers so you can use argc and argv
        ldr  r8, =argc
        str  r0, [r8]
        ldr  r8, =argv
        str  r1, [r8]

        @ Now let's print out the number of args you've passed:
        ldr  r4, =argc
        ldr  r1, [r4]
        ldr  r0, =msg1
        bl   printf

        @ If you have passed no args, we're done (first arg is filename)
        ldr  r0, =argc
        ldr  r1, [r0]
        cmp  r1, #1
        beq  _exit

        @ Let's print all the args you've passed now:
        ldr  r6, =argc
        ldr  r7, [r6]
        ldr  r4, =argv
        ldr  r5, [r4]
loop:
        cmp  r7, #1
        beq  _exit
        add  r5, #4
        ldr  r1, [r5] @ be careful here, argv is an array of pointers to the args!
        ldr  r0, =msg2
        bl   printf
        sub  r7, #1
        b    loop

_exit:
        pop  {r0-r8,ip,lr}
        mov  r8, #0
        swi  XOS_Exit

.section constants, "aS"
        .align 4
msg1:
        .asciz "argc: %d\n"
        .align 4
msg2:
        .asciz "argv: %s\n"
        .align 4

.data
        .align 4
argc:
        .long  0x00000000
argv:
        .long  0x00000000
        .align

Assembles and works fine here.

To assemble it, remember to use gcc (don’t use directly GAS), this approach uses the libc (note the printf around).

Good luck! :)

[edit]
In case more info are needed (or for less experienced people than Michael), I quickly published an article on my blog with more details and the Makefile I use:

https://paolozaino.wordpress.com/2023/08/10/assembly-arm32-retrieving-command-line-arguments-in-gnu-asm-gas-on-risc-os/
[/edit]

To assemble it, remember to use gcc (don’t use directly GAS), this approach uses the libc (note the printf around).

Can’t use libc :) So it doesn’t work. R0 and R1 doesn’t contain any useful stuff.

http://micken.se/pix/fpc_success.png

The pet project. Free pascal.

Can’t use libc :) So it doesn’t work. R0 and R1 doesn’t contain any useful stuff.

Then you could use elf2aif utility and convert the ELF into an AIF and use the traditional approach of using OS_GetEnv in your code.

Also please note “it doesn’t work” is a funny way of wording here. The approach works and works really well. Your requirements should have been stated though.

Your original post only mention:

I have a file assembled with gnu as and it doesn’t get arguments , only the executable from OS_GetEnv.
But only after installing latest libs from pacman. On my RPCemu/RISC OS Direct it works just fine.
I have a very simple test case if someone is interested.

The problem using OS_GetEnv etc. only happens if either you or your user have loaded DDEUtils module, so, you can also use OS_GetEnv with an ELF file, just make sure DDEUtils is not loaded.

Otherwise, if your requirements are: DDE Utils must be loaded, the executable must be in ELF format (but if you’re not using libc then I don’t see why this would be a requirement), and can’t use clib, then I’d suggest you to email the GCC team on their mail list.

Good luck! :)