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 <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