On 19/04/18 12:51, Theo Markettos wrote:
On Wed, Apr 18, 2018 at 01:44:45PM +0100, Duncan Moore wrote:
This is a bug report, but since the bug reporting list has been out of
action for some time, I'm sending it here.
Thanks. We should probably start a new issue tracker on github and migrate
across. (apologies for closing some of your bugs on the old system BTW - I
wasn't denying they were valid, just trying to reduce the amount of spamming
I was getting from bugzilla)
I have ELF and Absolute binaries getting different values of
__riscosify_control from UnixEnv$progname$nonametrans. It's the Absolute
binary that is giving the wrong result, and it only seems to happen when the
binary is run via a RISC OS variable containing the full pathname of the
Hmm... I'm not familiar with that code, but I'm puzzled. As far as I can
see elf2aif is simply slapping a pre-baked header on the ELF which does
zero-initialisation and then jumps to the ELF's entry point. Beyond a
handful of instructions they're identical.
__riscosify_control is a weak symbol so there *could* be something different
in linking, but here the linked binary is static and the difference is shown
with the same linked binary, with and without header.
So my guess is either that the header has some subtle side effect on the OS
that causes it to do different things, or that SOManager is changing things
when a statically linked ELF is run directly.
Lee, do you have any thoughts?
Yes, in the last AIF one, the code that constructs the system variable
name in Unixlib takes the program name as <Test$pathname>, so it's
looking for a variable called UnixEnv$<Test$pathname>$nonametrans which
When SOManager is responsible for starting the program, Test$pathname
is being expanded to the full filename, probably by the DDEUtils module,
so Unixlib finds the leaf name correctly.
So you're write that SOManager is changing things, but I don't think
it could be called a bug.
The best work around is to explicitly name the program in the code:
const char *const __program_name="testbin";
Unixlib will then always use this instead of the CLI.
GCCSDK mailing list email@example.com
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK