Conference caldec::wrl_atom

> ... We installed the Atom tool suite. This
> overwrites the standard DEC UNIX pixie with the Atom version of Pixie.

If I understand what you mean here, I think the statement is incorrect:

	- The /usr/bin/pixie command (which I figure you're calling "the 
	  standard DEC UNIX pixie") runs the Atom version of Pixie on V4.0.

	- The Atom tool suite is part of V4.0, including /usr/bin/pixie,
	  but we also provide more recent unsupported versions of the tools
	  for people who want them, as the Atom ADK. However, if you have
	  V4.0*, you do not particularly need to install the Atom ADK if
	  the tools in V4.0 are adequate. Indeed, if the ADK is causing
	  problems, the most immediate workaround may be to de-install it
	  and continue using the tools in the V4.0 base system subsets.

	- The original (MIPS) version of pixie is in
	  /usr/opt/obsolete/usr/bin/pixie, which I do not think is	
	  overwritten by the Atom ADK. If you had been using pixie on V3.2*, 
	  this obsolete version is the same thing, so try using it instead.

Having said that, I am very interested in any feature of the Atom Pixie
that makes it not work with programs that the MIPS pixie did support
(so please confirm if this is the case, because I would want to investigate
further), and also I think the Atom developer in our team might be able
to explain and/or fix the "ldgp" warnings that you report.

Adrian -

> We are using the Apex compiler supplied by Rational to build Ada 83
> executables under DEC UNIX 4.0. 

Please understand that we do not support instrumentation of applications 
created with third-party compilers.  Atom requires that compilers follow the
Calling Standard for Alpha Systems.  I have exchanged e-mail with the folks 
at Rational in the past.  They did try to follow the Calling Standard, but 
found it difficult to understand at times.  You may be running into one of 
those situations.  I would suggest that you contact Rational directly with 
this problem.

The two error messages are related.

> atom: Warning: Unable to find base of ldgp in object <prog_name> at
> <hexaddress>

This error message is saying that there is a load high instruction (ldah) 
off the GP without a related branch instruction or entry point preceding it.
Atom actually replaces these instructions with HALT instructions, on the
premise that no harm is done if the instruction is not executed.

> atom: Warning: Object '<prog_name>' has ldgp outside of procedure at
> <hexaddress>

This error messages occurs when Atom attempts to relocate the address from
the bad ldah instruction.


I hope this information helps.

Gail Lyons

[Posted by WWW Notes gateway]

Hi
	Thanks for that information. I'm trying to get more from the customer. 
He also has problems with the normal pixie , would there be a relationship?

"We are using the Apex compiler supplied by Rational to build Ada 83
>executables under DEC UNIX 3.2X. DEC UNIX 3.2 comes with a tool called Pixie.
>(The Atom suite installs another version of pixie but this email details the
>problems with the standard version.)
>
>Following the man page we run 
>
>pixie <programname>
>
>This gives the following output.
>
>Pixie registers: r26, r14 &r13
>old code = 6797104 bytes, new code = 17839532 bytes (2.6x)
>pixie: Warning: More than 2130 kbytes needed for the stacksize limit
>
>When the pixie'd program - <programname>.pixie - is run, the program runs
>fine for a while and then stops saying
>*MAIN PROGRAM ABANDONED - EXCEPTION "constraint_error" RAISED
>
>The UNIX command limit showed the shell's stacksize was 2048k
>
>I raised this by
>limit stacksize 4096k
>
>Unfortunately, this gave the same warning when I ran pixie on the code and
>the same error when I ran it."

Thanks


Adrian
[Posted by WWW Notes gateway]

The V3.2 pixie allocates the buffers (for counting executions of basic-blocks)
on the stack of the initial thread. That might be what is confusing the
Ada run-time system. It could also be that the instrumentation techniques
that pixie uses are not save with Apex. 

I usually set the stacksize to "unlimited" in situations
like this. Note that the V3.2 pixie is not thread-safe.

Hi
	The customer had a few more questions

>I'd be grateful if you would pass this on to your Atom group.
>
>Thanks
>
>David
>
>While I understand that you don't support third party compilers I'd like to
>explore some possible solutions to my problem. If Rational change their
>compiler output to follow DEC's Calling Standard for Alpha Systems, does this
>mean that executables generated by Rational's compiler suite will be
>compatible with the Atom tool?
>
>Is the Alpha Calling Standard stable? Or is it likely to change?
>
>Could DEC make the Atom interface a proprietary but open standard so
>third-party developers can build tools against it?
>
>What would be involved in getting the Atom source with a view to modifying it
>to work with the output from the Rational compiler?

ANy suggestions

Thanks very much for your help


Adrian
[Posted by WWW Notes gateway]

>While I understand that you don't support third party compilers I'd like to
>explore some possible solutions to my problem. If Rational change their
>compiler output to follow DEC's Calling Standard for Alpha Systems, does this
>mean that executables generated by Rational's compiler suite will be
>compatible with the Atom tool?
>

This statement is not quite the complete story, I think, though it is 
along the right lines. Atom depends on the executables complying with the
Calling Standard for (UNIX) Alpha Systems, and on the symbol table format
use by the "ld" linker, and on the various text and data segments, and
on characteristic instruction sequences (most of which are defined by the
calling standard, but there may be others that Atom depends on too).

So, the criterion for Atom working on a given executable is that the
executable be just like a GEM-based compiler would produce. Of course,
the criterion for use claiming support for anything is much more strict,
and so we do not claim to support Apex whatever the nature of its object 
files.

>Is the Alpha Calling Standard stable? Or is it likely to change?
>

The calling standard is fairly stable, but it can change, and does 
occaisionally. The object file conventions and symbol table change
frequently.

>Could DEC make the Atom interface a proprietary but open standard so
>third-party developers can build tools against it?
>

The Atom API is public, and third-party developers can build atom-based
tools. That doesn't make third-part compilers any more compatible.
I doubt that Atom's assumptions about object files can be standardized.

>What would be involved in getting the Atom source with a view to modifying it
>to work with the output from the Rational compiler?

This would be a business decision. I have asked my group's technical
director for his input on all these questions, and I will await his reply.
Our product manager Bill Zaharchuk would probably need to be involved too.
Currently, I believe the Atom source is not available outside this 
organization.

We have made inquiries about Rational's compiler suite for Digital UNIX.
Rational believes its Ada compiler complies with the Alpha Calling Standard.
Indeed, it uses enough of the COFF object file format for the Digital UNIX
"ld" to be the linker, and Rational considers it to be compatible with
the bulk of the ATOM tools, though this has not been exhaustively tested.

The DIGITAL/Rational team recommends that VADS 6.25f (or later) 
and Apex 2.2.3 (or later) are used when Atom is needed.
If there are things that Atom cannot find, it is only because the
DIGITAL/Rational team has not come across them yet. Please contact
Chris Murphy at [email protected] & [email protected] for more info.

In summary, while the Atom team does not ensure that Rational Ada is 
compatible with Atom, the Rational Ada team does intend that its compiler 
be compatible and remain so. 

I should also warn against trying to atomize threaded programs on V3.2
systems (though the immediate reported problem is instrumentation time
warnings) because Atom, Pixie, etc are designed to support the DECthreads
implementation used only by V4.0 and later systems. Also remember that
Atom ADK releases are not officially supported by Digital, meaning that
only the tools delivered as part of Digital UNIX V4.0 and later are
supported products. Significantly, this means that Atom is not supported
at all on V3.2* systems, even for DIGITAL compilers. However, if your
customer needs a fix for the original V3.2* "pixie" command, you could
enter a QAR in the OSF_QAR database on GORGE:: (with the QAR_INTERNAL 
account) so that we can investigate developing a patch kit.

Great
	Thanks very muchly.

Adrian
[Posted by WWW Notes gateway]