Re: [gccsdk] Absolute binaries giving incorrect __riscosify_control
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 , so it's looking for a variable called UnixEnv$$nonametrans which obviously fails. Shouldn't Unixlib really be expanding 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
Re: [gccsdk] Absolute binaries giving incorrect __riscosify_control
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 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 , so it's looking for a variable called UnixEnv$$nonametrans which obviously fails. 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. Lee. ___ 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
Re: [gccsdk] Absolute binaries giving incorrect __riscosify_control
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 > 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? Theo ___ 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
[gccsdk] Absolute binaries giving incorrect __riscosify_control
This is a bug report, but since the bug reporting list has been out of action for some time, I'm sending it here. 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. This demonstrates the problem: *Type c.noprocess #include #include int __riscosify_control; int main(int argc,char** argv) { (void) argc; printf("%s\t ",argv[0]); printf("%s\n",(__riscosify_control&__RISCOSIFY_NO_PROCESS) ? "RISCOS" : "UNIX"); return 0; } *Type run (a TaskObey file) Dir Set Test$dirname Set Test$pathname .testbin gcc -o testbin -static -Wl,-s noprocess.c Set UnixEnv$testbin$nonametrans "" Echo Binary is ELF testbin .testbin Echo Binary is Absolute elf2aif testbin testbin .testbin This is the output I get: Binary is ELF HostFS::HardDisc4.$.MyFiles.Transfer.testbin RISCOS HostFS::HardDisc4.$.MyFiles.Transfer.testbin RISCOS HostFS::HardDisc4.$.MyFiles.Transfer.testbin RISCOS Binary is Absolute HostFS::HardDisc4.$.MyFiles.Transfer.testbin RISCOS HostFS::HardDisc4.$.MyFiles.Transfer.testbin RISCOS /HostFS::HardDisc4.$/MyFiles/Transfer/testbin UNIX The binary should output the same text each time, but is wrong the last time. I'm using: gcc (GCCSDK GCC 4.7.4 Release 3) 4.7.4 SharedUnixLibrary 1.14 VirtualRPC-AdjustSA RISCOS 4.39 Regards Duncan Moore ___ 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