Limited success with 3.0 branch on AIX

[Elena Zannoni]

David Edelsohn writes:
 > 	First, I agree that the XFT_CV field of the File Auxilliary Entry
 > for C_FILE Symbols is the optimal location for this type of GCC DBX
 > Marker.  We just do not have a way of accessing that field with the
 > current tools.
 > 
 > 	What exactly is the "gcc2_compiled." symbol used to enable in GDB?
 > How much will it hurt if GDB debugs a GCC-compiled application and does
 > not know it was compiled with GCC?

It is looked for in dbxread.c and os9kread.c only.  It is used to set
the processing_gcc_compilation variable (which in other platforms is
set using different debug information). Such variable is then used in
VARIABLES_INSIDE_BLOCK (which I didn't notice before) defined for
sparc and arm, and for USE_STRUCT_CONVENTION (only the generic version
of the macro).

With regard to the first macro, I don't know if something running on
arm can have xcoff debug info, if not then, not being able to
distinguish between gcc 2 vs. older versions vs. native compilers
wouldn't be a problem.

About the the second macro, if the AIX targets don't use the generic
version of use_struct_convention, then it is already a non-problem.

 > 
 > 	We seem to have the following options:
 > 
 > 1) Do not include "gcc2_compiled." symbol in AIX XCOFF files until
 >    assembler provides feature to access XFT_CV field.
 > 2) Always use compatible assembler feature available now, e.g. C_GSYM.
 > 3) Use XFT_CV field if assembler supports the feature, otherwise fallback
 >    to C_GSYM.  Have GDB look in both locations, in addition to historical
 >    "gcc2_compiled." label.
 > 

I would prefer to do option 3, so that it would work no matter what.
But if we all agree that we can take the risk of not having gcc2_compiled
defined at all, then we are off the hook.

Elena


 > David
 >