On 20/04/2018 17:00, Lee Noar wrote:
On 19/04/18 12:51, Theo Markettos wrote:
On Wed, Apr 18, 2018 at 01:44:45PM +0100, Duncan Moore wrote:
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
binary.
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
obviously fails.
Shouldn't Unixlib really be expanding <Test$pathname> to the full
pathname, getting the leafname, and then looking for a variable called
UnixEnv$leafname$nonametrans?
_______________________________________________
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
