From mboxrd@z Thu Jan 1 00:00:00 1970 From: Elena Zannoni To: David Edelsohn Cc: Elena Zannoni , Kevin Buettner , "Zack Weinberg" , Matthew Conway , gcc@gcc.gnu.org, gcc-patches@gcc.gnu.org, gdb@sources.redhat.com Subject: Re: Limited success with 3.0 branch on AIX Date: Tue, 15 May 2001 16:19:00 -0000 Message-id: <15105.47488.332324.391947@kwikemart.cygnus.com> References: <15105.44346.860889.883125@kwikemart.cygnus.com> <200105152230.SAA25710@makai.watson.ibm.com> X-SW-Source: 2001-05/msg00265.html 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