Managers,
Originally if I compiled my c program with the -O option it would fail listing
different unresolved symbols, most notably, fprintf. If I took out the -O, the
compile would work just fine. However, it turns out -O was not the culprit after
all as I had thought. In the scope of this project, a number of developers felt
it necessary to include the -lc flag to compile their code. Well, needless to
say, we ended up with several -lc flags on the compile line, and I understand
the cc command appends one to the end on its own. This being the case,
we got strange compile results, most notably the aforementioned fprintf problem.
So, if you get wierd errors compiling while working on a project with several
other individuals, I guess it pays to make sure you don't have redundant flags.
I'm not sure still though, why taking the -O out would allow it to compile
(my guess is it has something to do with intrinsic(s)).
P.S.
For those of you who develop, I also ran across some "unaligned access"
error messages after compiling the code. We originally solved this by using the
-assume noaligned_objects compile flag until we found out it generated some
pretty crappy code. So, here's a tid bit I found on the web which helped out:
(Sorry I don't have the URL anymore - found it searching on yahoo - probably off
the DEC site - but I wish I could give credit to the author)
... Sean
P7. 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're only getting a
few of these messages, it might not matter, but if you're 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().
Received on Fri Mar 23 2001 - 20:22:14 NZST