Re: [gccsdk] Absolute binaries giving incorrect __riscosify_control

2018-04-22 Thread Duncan Moore 


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

2018-04-20 Thread Lee Noar 

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

2018-04-19 Thread Theo Markettos 
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