no arguments from Getenv
Pages: 1 2
Michael Grunditz (8594) 259 posts |
I have a file assembled with gnu as and it doesn’t get arguments , only the executable from OS_GetEnv. |
Paolo Fabio Zaino (28) 1882 posts |
Hey Michael,
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 |
Michael Grunditz (8594) 259 posts |
Works in RPCemu with whatever version of elfloader that in included in RO Direct.
I got the impression , with the project I am playing with, is that arguments is on the stack. (in linux) |
Rick Murray (539) 13850 posts |
How does ELFloader manage to screw up the environment string? Isn’t it supposed to be read only (unless explicitly set with OS_SetEnv)? |
David Pitt (9872) 363 posts |
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 |
David Pitt (9872) 363 posts |
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! |
Paolo Fabio Zaino (28) 1882 posts |
@ Michael
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. |
Paolo Fabio Zaino (28) 1882 posts |
I have seen it also on other devices, let me re-run all the tests (fun way to spend a Sunday afternoon! XD ) |
David Pitt (9872) 363 posts |
After a reboot all the arguments are now shown on the Titanium. |
Paolo Fabio Zaino (28) 1882 posts |
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:
While on RO you’d do the same (just different registers pointing at the args):
|
Paolo Fabio Zaino (28) 1882 posts |
Interesting, so what are we loading that messes it up???? |
Paolo Fabio Zaino (28) 1882 posts |
@ 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) |
David Pitt (9872) 363 posts |
Well spotted! Double clicking on GCC on both the Titanium and RPCemu stops it. |
David Pitt (9872) 363 posts |
It’s the DDEUtils module! |
Rick Murray (539) 13850 posts |
What on earth is GCC/SOM/whatever doing that would cause this to happen? |
Paolo Fabio Zaino (28) 1882 posts |
Boom! Confirmed, it’s DDEUtils messing up with the ElfLoader somehow. |
Michael Grunditz (8594) 259 posts |
@Paolo .. in thumb mode? :) |
Paolo Fabio Zaino (28) 1882 posts |
@ Michael
Hahah , sort of, more in “hurry mode” XD |
David Pitt (9872) 363 posts |
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. |
Rick Murray (539) 13850 posts |
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. */ 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. |
Michael Grunditz (8594) 259 posts |
Can’t get that to work. Can you give a working example (very simple, smallest possible)? |
Paolo Fabio Zaino (28) 1882 posts |
Of course:
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] |
Michael Grunditz (8594) 259 posts |
Can’t use libc :) So it doesn’t work. R0 and R1 doesn’t contain any useful stuff. |
Michael Grunditz (8594) 259 posts |
http://micken.se/pix/fpc_success.png The pet project. Free pascal. |
Paolo Fabio Zaino (28) 1882 posts |
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:
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! :) |
Pages: 1 2