This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Limited success with 3.0 branch on AIX
- To: David Edelsohn <dje at watson dot ibm dot com>
- Subject: Re: Limited success with 3.0 branch on AIX
- From: Elena Zannoni <ezannoni at cygnus dot com>
- Date: Tue, 15 May 2001 19:19:28 -0400
- Cc: Elena Zannoni <ezannoni at cygnus dot com>, Kevin Buettner <kevinb at cygnus dot com>, "Zack Weinberg" <zackw at Stanford dot EDU>, Matthew Conway <matt_conway at i2 dot com>, gcc at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org, gdb at sources dot redhat dot com
- References: <ezannoni@cygnus.com><15105.44346.860889.883125@kwikemart.cygnus.com><200105152230.SAA25710@makai.watson.ibm.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