[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: howto handle targets I can't execute

From: Joel Sherrill
Subject: Re: howto handle targets I can't execute
Date: Wed, 13 Feb 2008 14:24:23 -0600
User-agent: Thunderbird (X11/20071115)

Dave Korn wrote:
On 13 February 2008 19:44, Joel Sherrill wrote:

Dave Korn wrote:
On 13 February 2008 16:05, Joel Sherrill wrote:

What's the proper way to handle a target I don't have
a simulator or target hardware for?  Is there a standard
way to just go through the build sequence, not even
attempt to run anything and still report the results
in way that is meaningful?

  Yes, you can build a cross-targeted compiler and should at least get sane
results for e.g. the compile tests, only the execute tests actually
require a real target.

I want those to compile also.  Compile and link failures would
matter.  Is there a way to make that meaningful?

   Well, ...

  You could always compile "int main() { abort (); }" and supply it as a
stand-in for a real simulator if there's a hole in the framework needs
plugging :-)

Or one that printed "*** EXIT code 0

... will do for static link errors.  If you wanted to check for runtime
dynamic linking errors, perhaps your script could use the cross binutils to
determine whether every undefined symbol is resolved in the libs and output
"*** EXIT code" followed by an indication?
RTEMS is like VxWorks in that without a special ROM monitor
RTEMS doesn't do dynamic linking.  Most applications are static.

So for now, if it doesn't link static, then it is a failure.

Can't think of a witty .sigline today....

reply via email to

[Prev in Thread] Current Thread [Next in Thread]