Re: Limited success with 3.0 branch on AIX

[Elena Zannoni <ezannoni@cygnus.com>]

David Edelsohn writes:
 > 	C_INFO is a different type of storage class.  That is the storage
 > class of a symbol entry, not the DBX storage classes.  You need to look in
 > /usr/include/dbxstclass.h .
 > 
 > 	I do not think that assembly language can force a symbol into a
 > non-DBX storage class.
 > 
 > David
 > 

I see what you are saying. You don't want to use a storage class that
has a n_scnum other than N_DEBUG (if I interpret the manual
correctly), right?

How about C_FILE, then and use on of the auxillary entries to store
some compiler info? That seems to be what it is designed for:

"File Auxiliary Entry for C_FILE Symbols

The file auxiliary symbol table entry is defined to contain the source
file name and compiler-related strings. A file auxiliary entry is
optional and is used with a symbol table entry that has a storage-class
value of C_FILE. The C language structure for a file auxiliary entry
can be found in the x_file structure in the syms.h file.

The C_FILE symbol provides source file-name information, source-language
ID and CPU-version ID information, and, optionally, compiler-version
and time-stamp information."

This seems to be the correct way to handle this, maybe it is some more
work in GDB, but at least it will be right.

I am not a gcc/xcoff expert and I wouldn't be able to offer advice on
how to implement this on the gcc side. 
It seems that with x_file.x_ftype = XFT_CV we would get what we need?

Elena