Tru64-FAQ-Programming
Programming 1 -- What tools will help me port software to Digital UNIX?
The Digital Porting Assistant (available for Digital UNIX 3.2, and shipped as part of the developer toolkit on Digital UNIX 4.0) is a graphical environment which aids in the porting process. In addition to doing lint-like checking of C and Fortran code, it also contains extensive on-line help regarding developing software on Digital UNIX. Information about the Digital Porting Assistant can be found on the web at:
http://www.digital.com/info/porting_assistant
The version of lint shipped with Digital UNIX has many checks to help port software to Alpha. In particular, the -Q option is very useful. See the manual page for more details.
There is also a document/book entitled:
Interoperability, OpenVMS and DEC OSF/1
A company called Sector 7 deals with porting software from OpenVMS to Digital/Tru64 UNIX.
http://www.sector7.com
The -taso flag to cc will often help with making code work on the 64bit Alpha. This causes addresses to be 32-bits and should be used only as a last resort.
FreePort Express is a binary translator (running on Alpha) which permits you to convert your SunOS 4.1.x (same as Solaris 1.x) user executables into Digital UNIX executables in minutes. FreePort Express runs under Digital UNIX V3.0 or later, and is available FREE of charge (hence the name).
http://www.novalink.com/freeport-express
Programming 2 -- Why can't I run dbx?
The development environment is a separate layered product beyond the base OS. Although it is included on the Digital UNIX consolidated CD-ROM, the license must be purchased separately to use any portion of the Developer kit. Within the Digital UNIX Developer Kit the license just happens to be enforced by a check in dbx.
For more information:
http://www.digital.com/info/lists/dec-osf1-axp-SPD-anw.html
Developer Toolkit for Tru64 UNIX, Version 4.0F
Programming 3 -- Why do my applications not work after I upgrade to a new version of Digital UNIX?
Sometimes the details of the shared libraries change between releases. In general, applications compiled on an earlier version of Digital UNIX should still run on a later version. The converse may not be true.
The usual solution is to recompile from scratch.
Programming 4 -- Where can I get a debugging malloc that works on Tru64 UNIX?
Insure++ from ParaSoft at http://www.parasoft.com. Capable of detecting memory corruption, memory leaks, memory allocation errors, variable definition conflicts, I/O errors, pointer errors and library errors.
ftp://ftp.digital.com/pub/misc/malloc_dbg
(Has not been updated for a long time...)
If you get the package, be sure to read the stuff in the file contrib/dec_notes which explains how to replace malloc on the fly in an existing program.
The ATOM tools with Digital UNIX 3.0 and later also help with debugging memory allocation problems.
Sentinel, from AIB Software Corporation is a run-time analysis tool that supports memory access error detection as well as leak detection on Tru64 UNIX. More info, as well as free evaluation copies, is available from info@aib.com, or by calling 800-296-3000 (703-787-7700).
Programming 5 -- What's with 'ld: unresolved symbols: dnet_conn'?
Some libraries on Digital UNIX (notably the X11 library) are compiled so that they can use DECnet as well as TCP/IP. To link with such libraries, include -ldnet_stub at the end of link command. If you have DECnet software installed, use -ldnet.
Programming 6 -- How can I tell what program generated a core file?
1. Use the dbx debugger.
2. Use the "file" program (e.g., file
3. Use "strings" to find clues in the core file (e.g., strings)
Programming 7 -- What does "unaligned access" mean, and how can I fix it?
Unaligned accesses typically come up when programs use malloc(3) or other memory allocation routines in atypical ways, or when programs do certain (hazardous) kinds of type casts.
malloc(3) returns data aligned to the most restrictive alignment (8 byte boundaries). If you are writing your own malloc wrapper (say to add a reference count) and you write code like this:
char *mymalloc(int size)
{
short *newmem;
newmem = (short *) malloc(size + sizeof(short));
*newmem = 1; /* initialize reference count */
return (char *) (newmem + 1);
}
you are then returning a pointer that is no longer 8-byte aligned. Now, code like:
int *i;
i = (int *) mymalloc(sizeof(int));
*i = 10;
will generate unaligned access messages whenever *i is used.
An example of dangerous casting would be something like:
char buffer[100];
int i;
i = (int)*((int *)&buffer[3]);
The program will usually still run correctly, because an exception handler in the kernel performs an unaligned read. There are some rare cases, however, where the fixed read yields incorrect results. The messages are printed by default because one usually wants to know when a program is generating the unaligned accesses.
Now, if you are only getting a few of these messages, it might not matter, but if you are getting pages of them (or worse, have turned off the logger because you were getting so many unaligned access messages), you might consider correcting your program.
You can use the uac(1) (Unaligned Acces Message Control) command to turn off the messages.
If you want to find the the problem in the source code, you can use dbx. Suppose the message is:
Fixed up unaligned data access for pid 2337 (bozo) at pc 0x5ad364.
This tells you that the problem occurs in the program "bozo". In dbx, you would type, for example:
% dbx bozo
(dbx) 0x5ad364/i
*[main:206, 0x0x5ad364] lw r0,40(sp)
dbx prints the offending instruction, along with its location: line 206 in main().
Programming 8 -- What about "unaligned access" in FORTRAN programs?
This is most often caused by COMMON blocks in which variables are not naturally aligned. For example:
REAL*4 X
REAL*8 Y
COMMON /CMN/ X,Y
Y will be at offset 4, which is not a multiple of its size (
. The best solution is to rearrange variables in the COMMON so that real, complex and integer variables are listed in order of decreasing size, followed by CHARACTER variables. Put your declaration in an INCLUDE file to make sure all uses are consistent! You can also ask the compiler to automatically add padding to align variables through the -align dcommons switch, or through a CDEC$ OPTIONS directive. See the DEC Fortran User Manual for further details.
Programming 9 -- How can I get microsecond resolution from gettimeofday(2)?
Normally, Digital UNIX updates its internal idea of the current time once per clock tick (1024 Hz, or about once per millisecond). In Digital UNIX V4.0 and later, it is possible to rebuild the kernel to support approximately microsecond resolution from the gettimeofday(2) system call, and from the various library routines that use this system call.
To enable this option, add the following line to the kernel configuration file and rebuild the kernel:
options MICRO_TIME
The system clock (CLOCK_REALTIME) resolution as returned by clock_getres(3) will not change. Timer resolution remains the same. However, the granularity of the time returned by gettimeofday(2) and clock_gettime(3) will now be in microseconds. The time values returned are SMP safe and monotonically increasing.
The high-resolution clock can be used for timestamping and for measuring durations on the order of microseconds, such as time spent in some critical code path.
| jxnuxdy 回复于：2003-05-14 11:05:17 |
| 兄弟，知道在True64下怎样加入自已的驱动程序，
在linux下，我们就用insmod X.o搞定? |
| 我爱臭豆腐 回复于：2003-05-14 11:32:18 |
| 你说的是什么驱动?这要看它是否支持tru64了?如果是它自己的产品都能够支持最多就是下载一个更新的补丁. |
| jxnuxdy 回复于：2003-05-14 14:37:42 |
| 我写了linux主机的串口驱动程序，在linux下运行很好，现在我想把它称植到True64下面，我看了一下:
http://www.china-pub.com/computers/emook/1195/info.htm 这里面讲得跟linux下差不多的思路，但若要在Tr64下实现刚才那个链接文章里的东东，该是怎样写？提点建议，谢谢! |
| jxnuxdy 回复于：2003-05-14 14:39:32 |
| 我写了linux主机的串口驱动程序，在linux下运行很好，现在我想把它称植到True64下面，我看了一下:
http://www.china-pub.com/computers/emook/1195/info.htm 这里面讲得跟linux下差不多的思路，但若要在Tr64下实现刚才那个链接文章里的东东，该是怎样写？提点建议，谢谢! |
| 我爱臭豆腐 回复于：2003-05-14 14:56:27 |
哥们这个我就帮助不上您了.我对c的编程一点都不了解 |
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
