Ticket #1840 (new feature)

Opened 4 years ago

Last modified 3 years ago

Config step to detect RTEMS

Reported by: dukeleto Owned by: dukeleto
Priority: normal Milestone:
Component: configure Version: 2.10.0
Severity: medium Keywords: RTEMS
Cc: Language:
Patch status: Platform:

Description

We need a config step that checks for rtems and sets the parrot_config key of 'rtems' to true or false, depending on whether the symbol is defined.

Change History

  Changed 4 years ago by jkeenan

  • component changed from none to configure

  Changed 4 years ago by dukeleto

We probably want to actually store the string 'rtemsx.x' where x.x is the version of RTEMS in whichever config key stores the name of the operating system.

  Changed 4 years ago by jkeenan

  • status changed from new to assigned

Adding link for reference to  rtems.com.

BTW, their web site has a great discussion of their use of  Coverage Analysis in testing.

kid51

follow-up: ↓ 10   Changed 4 years ago by doughera

> Comment(by dukeleto):
> 
>  We probably want to actually store the string 'rtemsx.x' where x.x is the
>  version of RTEMS in whichever config key stores the name of the operating
>  system.

"osname" is currently set by config/auto/arch.pm, based on perl5's 
$Config{archname}, which, in turn, is based on the output of `uname -a`, 
along with a lot of other heuristics accumulated over the years. 
Presumably, there is some existing file one could test for or existing 
command one could run to determine if this is RTEMS or not.

Parrot doesn't generally use perl5's Config{osvers}, though parrotbug uses 
it in bug reports.  Oddly, init/hints/freebsd.pm recomputes $osversion, 
but never uses it.  I think it would make sense to add an "osvers" key to 
the existing "cpuarch" and "osname" keys in the config/auto/arch.pm step.

--
    Andy Dougherty		doughera@lafayette.edu


in reply to: ↑ description ; follow-up: ↓ 6   Changed 4 years ago by jkeenan

Replying to dukeleto:

We need a config step that checks for rtems and sets the parrot_config key of 'rtems' to true or false, depending on whether the symbol is defined.

dukeleto:

Please do a checkout of the gcc_defines branch from Subversion and configure on the machine where you have RTEMS. Then call grep -i gccdefines__rtems__ lib/Parrot/Config/Generated.pm config_lib.pir. Then tell me if you can take it from there.

(Don't merge. There are other issues I'll deal with.)

Thank you very much.

kid51

in reply to: ↑ 5 ; follow-up: ↓ 7   Changed 4 years ago by doughera

Replying to jkeenan:

Please do a checkout of the gcc_defines branch from Subversion and configure on the machine where you have RTEMS. Then call grep -i gccdefines__rtems__ lib/Parrot/Config/Generated.pm config_lib.pir. Then tell me if you can take it from there.

I'm unsure if this will be useful. For comparison, perl 5's Configure also attempts to figure out the symbols #defined for the the current C preprocessor. It's over 200 lines of shell code, running from line 21,467 to 21,687 in Configure. The output is stored in $Config{cppsymbols}. As far as I know, the output is no longer ever used.

Within C code, if you want to check #ifdef __rtems__, you simply do so. You don't need any Configure probe. Outside of C code, I agree you need to run some kind of probe, but this looks overly complicated to me. As I have mentioned previously in this ticket, I think the osname probe is the more natural place to do this.

in reply to: ↑ 6 ; follow-up: ↓ 8   Changed 4 years ago by jkeenan

Replying to doughera:

Outside of C code, I agree you need to run some kind of probe .... [T]he osname probe is the more natural place to do this.

Andy,

Thanks for taking another look at this.

Here I'm bumping up against the limits of my understanding of the problem we're trying to address in this ticket. Are we:

* checking to see whether the OS on which we are trying to configure and build Parrot is RTEMS? If so, then I would ask dukeleto: What do you get on your RTEMS box for osname in lib/Parrot/Config/Generated.pm.

or:

* checking to determine whether the box on which we are working (and which is presumably capable of compiling Parrot) is capable of (cross-)compiling RTEMS?

kid51

in reply to: ↑ 7   Changed 4 years ago by doughera

Replying to jkeenan:

Replying to doughera:

Here I'm bumping up against the limits of my understanding of the problem we're trying to address in this ticket. Are we: * checking to see whether the OS on which we are trying to configure and build Parrot is RTEMS? or: * checking to determine whether the box on which we are working (and which is presumably capable of compiling Parrot) is capable of (cross-)compiling RTEMS?

I think it's more the latter. Parrot's configure system doesn't include separate concepts of "host" and "target" systems, so something is going to have to force it somewhere. Somehow, in the command-line invocation of Configure.pl, the user must indicate that cross-compiling is desired.

There are many ways one might imagine that working, and, hence, many different ways one might imagine the relevant Configure steps working. Hence confusion results.

I think that dukeleto might have the following scenario in mind:

If the user wishes to cross-compile for RTEMS, then he or she specifies the cross-compiler for the -cc= (and -ld=, -link=, etc.) command-line options to Configure.pl. Then, in auto:cpuarch, Configure.pl could build the following simple program

#include <stdlib.h>
int main(int argc, char **argv)
{
#ifdef __rtems__
    exit EXIT_SUCCESS;
#else
    exit EXIT_FAILURE;
#endif
}

compile it with the supplied compiler, run it, and check the return status. I don't know RTEMS at all, so I don't know how one actually runs such a cross-compiled command. For some cross-compilation set-ups, actually running the command is difficult (it requires transferring the compiled program to another device.) In such cases, it might be better to try just compiling something like this instead:

#include <stdlib.h>
int main(int argc, char **argv)
{
#ifdef __rtems__
    exit EXIT_SUCCESS;
#else
    error_undefined_variable;
#endif
}

If this compiles at all, then we are on rtems. This would solve the immediate problem, but I suspect it will be insufficient to solve the whole cross-compiling program. Other parts of the build system will also likely need to become cross-compiling aware.

Ideally, it would be nice to determine that osname=rtems (and hence that we are cross-compiling) much earlier in the process (before init::hints) so that one could write and use a config/init/hints/rtems.pm hint file, instead of sprinkling if($PConfig{$rtems}) statements throughout all the other config files. If Configure.pl allowed the user to specify arbitrary config keys from the command line, one might imagine accomplishing this by writing something like

Configure.pl --with-osname=rtems

but Configure.pl does not currently allow that. Alternatively, the autoconf cross-compilation command-line syntax might offer a good model for what users would actually like to do, but extending Configure.pl in that direction is a different job for a different ticket.

I hope this helps a little.

  Changed 4 years ago by dukeleto

The code snippets above are exactly what is needed by the C probe. Cross-compiling concerns will be taken care of in other tickets.

I agree with Andy that we will need a config/init/hints/rtems.pm in the future.

in reply to: ↑ 4   Changed 4 years ago by jkeenan

Replying to doughera:

> 
> I think it would make sense to add an "osvers" key to 
> the existing "cpuarch" and "osname" keys in the 
> config/auto/arch.pm step.
> 

I've created TT #1841 to discuss this issue by itself.

kid51

  Changed 4 years ago by jkeenan

Try svn up again after r49770.

follow-up: ↓ 13   Changed 4 years ago by jkeenan

  • milestone 2.10 deleted

in reply to: ↑ 12   Changed 4 years ago by jkeenan

  • status changed from assigned to new
  • owner changed from jkeenan to dukeleto

Replying to jkeenan:

dukeleto:

Since there is nothing more I can do about this issue right now, I am going to reassign this ticket to you. You can take it up whenever you get back to hacking on RTEMS.

Thanks.

kid51

  Changed 3 years ago by jkeenan

  • keywords RTEMS added
Note: See TracTickets for help on using tickets.