[Cdash] Something is rotten in the (64-bit) state of (CDash)
David Cole
david.cole at kitware.com
Wed Aug 25 16:39:47 UTC 2010
[This is really more sort of a blog post of information than a question that
needs answering. But it seems more appropriate to start here, by posting it
to the CDash mailing list...]
In CDash, a "site" is a representation of a client testing machine that is
submitting builds to it.
If you click on the name of a site on a CDash result page, you see
information about that computer. For example, the following pages are for
Kitware's dashboard machines, dash2win64 and dash1vista32
http://www.cdash.org/CDash/viewSite.php?siteid=2012&project=1¤ttime=1282698000
http://www.cdash.org/CDash/viewSite.php?siteid=20&project=1¤ttime=1282698000
As you can see from viewing the viewSite.php page, there is a field
associated with the site presented as "64 Bits" -- it looks like it should
have values of 0 and 1 for different machines. With names like dash2win64
and dash1vista32, you'd probably expect that you'd have a 1 and a 0. But
they're both 0... what's going on here?
Well, let's look at the source. The value for "64 Bits" comes to CDash in
xml file submissions. Typically, these xml files are produced by ctest
running on the client. The Build.xml, Configure.xml and Test.xml files all
have a "<Site>" XML element at the top of the file with an "Is64Bits"
attribute. The code that writes that attribute value is in the method
cmCTest::StartXML, and it looks like this:
cmsys::SystemInformation info;
info.RunCPUCheck();
info.RunOSCheck();
info.RunMemoryCheck();
...
<< "\tIs64Bits=\"" << info.Is64Bits() << "\"\n"
...
The problem is, the code info.Is64Bits() reflects the answer to the question
"is the ctest process that I am running right now built as a 32-bit or
64-bit application". It does *not* answer the question, "is the machine/OS
on which I am running capable of running 64-bit applications?"
Here's the implementation:
bool SystemInformationImplementation::Is64Bits()
{
return (sizeof(void*) == 8);
}
As you can see, it clearly returns whether the called code was compiled as
64-bit or not... not anything to do with the machine or the OS at all.
Unfortunately for all of us, I think the majority of the people who are
looking at this stuff on CDash and in the XML files *assume* incorrectly
that Is64Bits means: is the machine a 64-bit machine? In fact, what it
really means, is: was the ctest that submitted from this site a 32-bit or a
64-bit build of ctest? And that is essentially useless information in terms
of the typical project on the typical CDash server. Especially when folks
use the pre-built binaries from Kitware. At present, on Windows, it's always
a 32-bit build of ctest, and Is64Bits is always 0.
Much more interesting and useful would be:
- for the site object, what architectures is the site *capable* of running?
- for a given build, what is/are the architecture(s) of each library and
executable built and tested?
- for a given submission, what are the architectures of the submitting
client (ctest itself, may or may not be interesting...)
This is almost always a list of architectures, not a boolean.
Think: universal binaries on the Mac may contain multiple architectures
within the same file. You have to dig and analyze even to figure out which
architecture is running as an end-user. And 32-bit Windows apps work just
swell on 64-bit machines. Similarly for x86 Linux code on an x86_64 machine.
Everybody's got runtime compatibility layers that allow executing software
built for earlier architectures on newer hardware and OSes.
Until this "64 Bits" field is eliminated from the viewSite page of CDash,
confusion will abound. Hopefully this article clears up a little bit of it.
If nothing else, hopefully I've convinced you to stop looking at the "64
Bits" field for now.
David Cole
Kitware, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cdash/attachments/20100825/895a6521/attachment-0002.htm>
More information about the CDash
mailing list