Re: Limited success with 3.0 branch on AIX

Re: Limited success with 3.0 branch on AIX

[David Edelsohn]

	I would like to refer the GDB experts to a question on the GCC
mailinglist in regard to Zack Weinberg's gcc2_compiled changes.  His patch
to implement DBX_OUTPUT_GCC_MARKER support on AIX was not completely
correct.  He used stabs N_OPT type which is not valid on AIX and does not
correspond to any AIX storage class stabx type.

	The closest AIX type seems to be C_GSYM (stabs N_GSYM).  Does GDB
for AIX care about the gcc2_compiled symbol?  Is using the N_GSYM type
(whose value is ignored, according to the documentation) okay?  The
semantics of a global symbol seem the closest to a N_OPT comment.  I do
not understand enough about the significance of the stab type to know if
this proposal would be satisfactory.

http://gcc.gnu.org/ml/gcc-patches/2001-04/msg01459.html

Thanks, David

Re: Limited success with 3.0 branch on AIX

[Daniel Berlin]

On Tue, 1 May 2001, David Edelsohn wrote:

> 	I would like to refer the GDB experts to a question on the GCC
> mailinglist in regard to Zack Weinberg's gcc2_compiled changes.  His patch
> to implement DBX_OUTPUT_GCC_MARKER support on AIX was not completely
> correct.  He used stabs N_OPT type which is not valid on AIX and does not
> correspond to any AIX storage class stabx type.
>
> 	The closest AIX type seems to be C_GSYM (stabs N_GSYM).  Does GDB
> for AIX care about the gcc2_compiled symbol?  Is using the N_GSYM type
> (whose value is ignored, according to the documentation) okay?  The
> semantics of a global symbol seem the closest to a N_OPT comment.  I do
> not understand enough about the significance of the stab type to know if
> this proposal would be satisfactory.

Right now, gdb only happens to look for it in a few types of stabs.

N_GSYM is not one of them.

Though it's trivial to change gdb to allow gcc2_compiled to appear in
that symbol. It's a one liner, literally.

--Dan
>
> http://gcc.gnu.org/ml/gcc-patches/2001-04/msg01459.html
>
> Thanks, David
>

Re: Limited success with 3.0 branch on AIX

[David Edelsohn]

	The AIX stab-like choices are:

#define C_GSYM          0x80
#define C_LSYM          0x81
#define C_PSYM          0x82
#define C_RSYM          0x83
#define C_RPSYM         0x84
#define C_STSYM         0x85
#define C_TCSYM         0x86
#define C_BCOMM         0x87
#define C_ECOML         0x88
#define C_ECOMM         0x89
#define C_DECL          0x8c
#define C_ENTRY         0x8d
#define C_FUN           0x8e
#define C_BSTAT         0x8f
#define C_ESTAT         0x90

	C_GSYM seemed to make the most sense to me.  Would gdb looking in
N_GSYM cause a problem for any other ports?  Should gdb look there only
for AIX?

	Would N_GSYM symbol cause a conflict if a programmer really chose
to declare a global symbol named "gcc2_compiled."?  Given the definition
of N_GSYM, it seems that this only would define a duplicate stabs entry
and not conflict with a real symbol of that same name because the stabs
value is ignored.

	I would like to get a patch into GCC ASAP, but I want it to match
what GDB expects / can handle.  So I would like to get a decision to use
G_NSYM or an alternate AIX stabs type, and get the simple changes into GCC
and GDB.

Thanks, David

Re: Limited success with 3.0 branch on AIX

[Kevin Buettner]

On May 1,  4:21pm, David Edelsohn wrote:

> 	I would like to get a patch into GCC ASAP, but I want it to match
> what GDB expects / can handle.  So I would like to get a decision to use
> G_NSYM or an alternate AIX stabs type, and get the simple changes into GCC
> and GDB.

What changes do you think GDB will require?

Kevin

Re: Limited success with 3.0 branch on AIX

[David Edelsohn]

>>>>> Kevin Buettner writes:

Kevin> What changes do you think GDB will require?

	I presume only the one line change to which Daniel referred in his
message:

> Right now, gdb only happens to look for it in a few types of stabs.

> N_GSYM is not one of them.

> Though it's trivial to change gdb to allow gcc2_compiled to appear in
> that symbol. It's a one liner, literally.

David

Re: Limited success with 3.0 branch on AIX

[Kevin Buettner]

On May 1,  1:12pm, David Edelsohn wrote:

> 	The closest AIX type seems to be C_GSYM (stabs N_GSYM).  Does GDB
> for AIX care about the gcc2_compiled symbol?

I didn't think so at first, but now that I've looked at it for a
while, I see that rs6000-tdep.c uses generic_use_struct_convention()
which cares about whether "gcc2_compiled." was seen when reading the
symbols.

> Is using the N_GSYM type (whose value is ignored, according to the
> documentation) okay?

It looks okay to me, but I'm not a stabs expert.  

> The semantics of a global symbol seem the closest to a N_OPT
> comment.  I do not understand enough about the significance of the
> stab type to know if this proposal would be satisfactory.
> 
> http://gcc.gnu.org/ml/gcc-patches/2001-04/msg01459.html

What was the convention used by gcc on AIX prior to Zack Weinberg's
changes?

Kevin

Re: Limited success with 3.0 branch on AIX

[David Edelsohn]

>>>>> Kevin Buettner writes:

Kevin> What was the convention used by gcc on AIX prior to Zack Weinberg's
Kevin> changes?

	GCC used to create the symbol as a label.  I don't know if GDB
actually looked for the symbol directly or for the debugging information
associated with the symbol:

.csect .text[PR]
gcc2_compiled.:
__gnu_compiled_c:


David

Re: Limited success with 3.0 branch on AIX

[Zack Weinberg]

On Mon, Apr 30, 2001 at 05:16:49PM -0400, David Edelsohn wrote:
> >>>>> Matthew Conway writes:
> 
> Matthew> "ar -rc libFooBar.a Foo.o Bar.o"
> Matthew> "BFD: Foo.o: Unrecognized storage class 60 for *ABS* symbol `gcc2_compiled.'"
> Matthew> "BFD: Bar.o: Unrecognized storage class 60 for *ABS* symbol `gcc2_compiled.'"
> 
> Matthew> What does it mean? Can I safely ignore it?  Should I get the latest
> Matthew> binutils snapshot?  If I do get the latest binutils, have the problems
> Matthew> that forced me to use the gnupro assembler been fixed yet?  Thanks,
> 
> 	Zack's STABS_GCC_MARKER change still is not fully correct for AIX,
> despite his attempt at DBX_OUTPUT_GCC_MARKER in xcoffout.h:
> 
> /* .stabx has the type in a different place.  */
> #define DBX_OUTPUT_GCC_MARKER(FILE) \
>   fprintf ((FILE), "%s\"%s\",0,%d,0\n", ASM_STABS_OP, STABS_GCC_MARKER, N_OPT)
> 
> This directly emits a stabs type (N_OPT) in the AIX .stabx directive when
> all stabs are suppose to be converted to AIX storage classes.

Sorry.  This was not clear from the code.

...
> 	I do not see anything in the AIX equivalent to N_OPT -- no comment
> storage class.  Would using N_GSYM (AIX's C_GSYM) be appropriate?  It
> seems to be a stab for which only the name is significant, not the value,
> which matches the use of gcc2_compiled.

The question is whether gdb on AIX will notice the marker in a C_GSYM
.stabx directive; also whether the native debugger will choke on it.
I've cc:ed the gdb folks for comment.  Leaving your patch quoted so
they can look at it.

zw

> 	Does anyone see a problem with the following patch?  I am not
> enough of an expert about DBX Stabs to know the significance of this
> choice of stab type.
> 
> 
> 	* xcoffout.h (DBX_OUTPUT_GCC_MARKER): Use N_GSYM, not N_OPT.
> 
> Index: xcoffout.h
> ===================================================================
> RCS file: /cvs/gcc/egcs/gcc/xcoffout.h,v
> retrieving revision 1.10.4.1
> diff -c -p -r1.10.4.1 xcoffout.h
> *** xcoffout.h	2001/04/18 06:15:20	1.10.4.1
> --- xcoffout.h	2001/04/30 21:11:18
> *************** extern const char *xcoff_lastfile;
> *** 174,180 ****
>   
>   /* .stabx has the type in a different place.  */
>   #define DBX_OUTPUT_GCC_MARKER(FILE) \
> !   fprintf ((FILE), "%s\"%s\",0,%d,0\n", ASM_STABS_OP, STABS_GCC_MARKER, N_OPT)
>   
>   /* Do not break .stabs pseudos into continuations.  */
>   #define DBX_CONTIN_LENGTH 0
> --- 174,181 ----
>   
>   /* .stabx has the type in a different place.  */
>   #define DBX_OUTPUT_GCC_MARKER(FILE) \
> !   fprintf ((FILE), "%s\"%s\",0,%d,0\n", ASM_STABS_OP, STABS_GCC_MARKER, \
> ! 	   stab_to_sclass (N_GSYM))
>   
>   /* Do not break .stabs pseudos into continuations.  */
>   #define DBX_CONTIN_LENGTH 0
> 
> 
> David

Re: Limited success with 3.0 branch on AIX

[Kevin Buettner]

On May 2, 11:24pm, Zack Weinberg wrote:

> > 	I do not see anything in the AIX equivalent to N_OPT -- no comment
> > storage class.  Would using N_GSYM (AIX's C_GSYM) be appropriate?  It
> > seems to be a stab for which only the name is significant, not the value,
> > which matches the use of gcc2_compiled.
> 
> The question is whether gdb on AIX will notice the marker in a C_GSYM
> .stabx directive; also whether the native debugger will choke on it.
> I've cc:ed the gdb folks for comment.  Leaving your patch quoted so
> they can look at it.

David asked about this on the GDB list recently.  I see nothing wrong
with David's approach, though GDB will require a minor modification to
recognize "gcc2_compiled." as an N_GSYM.

See:

    http://sources.redhat.com/ml/gdb/2001-05/msg00015.html
    http://sources.redhat.com/ml/gdb/2001-05/msg00019.html
    http://sources.redhat.com/ml/gdb/2001-05/msg00020.html
    http://sources.redhat.com/ml/gdb/2001-05/msg00027.html
    http://sources.redhat.com/ml/gdb/2001-05/msg00028.html
    http://sources.redhat.com/ml/gdb/2001-05/msg00030.html
    http://sources.redhat.com/ml/gdb/2001-05/msg00033.html

I will note, however, that neither of GDB's symtabs maintainers
have weighed in on this issue yet.

Kevin

Re: Limited success with 3.0 branch on AIX

[Elena Zannoni]

Jim is away from his mail at the moment, but I just talked with him on
the phone about this. 

We were thinking about C_INFO as a possibility. Whether we use C_GSYM
or C_INFO, xcoffread.c will have to get the name of the symbol, but
C_INFO is much less likely to occur, thus the overhead would be less.

The definition of C_INFO is in /usr/include/storclass.h on an AIX
machine.  I saw it mentioned in a patch by Tom Rix on the binutils
mailing list, as well:
http://sources.redhat.com/ml/binutils/2001-01/msg00448.html

For the C_INFO, if we chose to go with that, we would have to write
similar code to what dbxread.c, process_one_symbol() does for N_OPT,
and that would go in xcoffread.c, read_xcoff_symtab() instead:

      /* We use N_OPT to carry the gcc2_compiled flag.  Sun uses it
         for a bunch of other flags, too.  Someday we may parse their
         flags; for now we ignore theirs and hope they'll ignore ours.  */
    case N_OPT:		/* Solaris 2:  Compiler options */
      if (name)
	{
	  if (STREQ (name, GCC2_COMPILED_FLAG_SYMBOL))
	    {
	      processing_gcc_compilation = 2;
#if 0				/* Works, but is experimental.  -fnf */
	      /* For now, stay with AUTO_DEMANGLING for g++ output, as we don't
		 know whether it will use the old style or v3 mangling.  */
	      if (AUTO_DEMANGLING)
		{
		  set_demangling_style (GNU_DEMANGLING_STYLE_STRING);
		}
#endif
	    }
	  else
	    n_opt_found = 1;
	}
      break;


Elena



Kevin Buettner writes:
 > On May 2, 11:24pm, Zack Weinberg wrote:
 > 
 > > > 	I do not see anything in the AIX equivalent to N_OPT -- no comment
 > > > storage class.  Would using N_GSYM (AIX's C_GSYM) be appropriate?  It
 > > > seems to be a stab for which only the name is significant, not the value,
 > > > which matches the use of gcc2_compiled.
 > > 
 > > The question is whether gdb on AIX will notice the marker in a C_GSYM
 > > .stabx directive; also whether the native debugger will choke on it.
 > > I've cc:ed the gdb folks for comment.  Leaving your patch quoted so
 > > they can look at it.
 > 
 > David asked about this on the GDB list recently.  I see nothing wrong
 > with David's approach, though GDB will require a minor modification to
 > recognize "gcc2_compiled." as an N_GSYM.
 > 
 > See:
 > 
 >     http://sources.redhat.com/ml/gdb/2001-05/msg00015.html
 >     http://sources.redhat.com/ml/gdb/2001-05/msg00019.html
 >     http://sources.redhat.com/ml/gdb/2001-05/msg00020.html
 >     http://sources.redhat.com/ml/gdb/2001-05/msg00027.html
 >     http://sources.redhat.com/ml/gdb/2001-05/msg00028.html
 >     http://sources.redhat.com/ml/gdb/2001-05/msg00030.html
 >     http://sources.redhat.com/ml/gdb/2001-05/msg00033.html
 > 
 > I will note, however, that neither of GDB's symtabs maintainers
 > have weighed in on this issue yet.
 > 
 > Kevin
 > 

Re: Limited success with 3.0 branch on AIX

[David Edelsohn]

	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

Re: Limited success with 3.0 branch on AIX

[Elena Zannoni]

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

Re: Limited success with 3.0 branch on AIX

[David Edelsohn]

	I can generate "gcc2_compiled." as a C_FILE entry using the
".file" assembler pseudo-op, but the value of interest is pointed to by
the entry, not the entry itself.  The following is the output of dumping
the symbol table:

[0]     m   0x00000002        -2     1    0x67         0x0000     .file
[1]     a0                                                        gcc2_compiled.
[2]     m   0x00000007        -2     1    0x67         0x0000     .file
[3]     a0                                                        note.c
[4]     m   0x00000000         1     1    0x6b         0x0000     .text
[5]     a4  0x00000000       0    0     17    0        0    0
[6]     m   0x00000000        -2     0    0x80         0x0000     gcc2_compiled.

Lines 0 and 1 are the extra C_FILE entry.  Line 6 is the DBX C_GSYM that I
proposed.  GDB can find the value of the File Auxilliary Entry associated
with the C_FILE symbol, but it takes some extra groveling.

	I can force the value into the C_FILE entry itself, but it is not
portable and not correct.

	I am worried about having two ".file" directives in a single
assembly file as ".file" is suppose to provide scope.  Compare an object
file produced by IBM's XLC compiler:

[0]     m   0x00000000        -2     3    0x67         0x0003     .file
[1]     a0                                                        bss.c
[2]     a0                                                        Wed May 16 13:32:41 2001 
[3]     a0                                                        IBM C and C++ Compilers Version 3.6.6.0 ---

A single C_FILE entry containing the filename (XFT_FN), compiler timestamp
(XFT_CT), and compiler version number (XFT_CV).

	I don't think that emitting a second ".file" directive is safe
because that is placing "gcc2_compiled." into the source file field.  I
have not been able to find a way to generate multiple File Auxilliary
Entries associated with a single C_FILE symbol using assembly pseudo-ops.

	All of the discussion about C_FILE and other storage classes is in
the context of XCOFF object files.  IBM's compilers generate object files
directly, without an intermediate assembler step.  There does not appear
to be a way to set the x_ftype field of the File Auxiliary Entry from the
assembler.

	I will investigate further, but the primary functionality at our
disposal is the ".stabx" directive which is limited to the DBX storage
classes listed in dbxstclass.h.

David

Re: Limited success with 3.0 branch on AIX

[David Edelsohn]

	As a follow up, compiling file bss.c with IBM's XLC compiler
produces bss.o containing:

[0]     m   0x00000000        -2     3    0x67         0x0003     .file
[1]     a0                                                        bss.c
[2]     a0                                                        Wed May 16 14:08:13 2001 
[3]     a0                                                        IBM C and C++ Compilers Version 3.6.6.0 --- 

Disassembling bss.o produces an assembly file containing the directive

	.file   "bss.c"

Assembling the disassembled file produces a new object file containing:

[0]     m   0x00000000        -2     1    0x67         0x0003     .file
[1]     a0                                                        bss.c


	IBM's AIX assembler (and the GNU assembler) do not allow access to
all of the user-settable internal structure of XCOFF files.  This is a
known limitation.  There is no way to insert the information into the most
appropriate XCOFF location for compiler version or compiler-defined
information. 

David

Re: Limited success with 3.0 branch on AIX

[Elena Zannoni]

David Edelsohn writes:
 > 	As a follow up, compiling file bss.c with IBM's XLC compiler
 > produces bss.o containing:
 > 
 > [0]     m   0x00000000        -2     3    0x67         0x0003     .file
 > [1]     a0                                                        bss.c
 > [2]     a0                                                        Wed May 16 14:08:13 2001 
 > [3]     a0                                                        IBM C and C++ Compilers Version 3.6.6.0 --- 
 > 
 > Disassembling bss.o produces an assembly file containing the directive
 > 
 > 	.file   "bss.c"
 > 
 > Assembling the disassembled file produces a new object file containing:
 > 
 > [0]     m   0x00000000        -2     1    0x67         0x0003     .file
 > [1]     a0                                                        bss.c
 > 
 > 
 > 	IBM's AIX assembler (and the GNU assembler) do not allow access to
 > all of the user-settable internal structure of XCOFF files.  This is a
 > known limitation.  There is no way to insert the information into the most
 > appropriate XCOFF location for compiler version or compiler-defined
 > information. 

Obviously this prompts the question: can the limitation be eliminated, i.e.
can the correct functionality be provided? 

If not, we'll have to use a different approach. And looks like using C_GSYM
could be the one.


Elena


 > 
 > David
 > 

Re: Limited success with 3.0 branch on AIX

[David Edelsohn]

>>>>> Elena Zannoni writes:

Elena> Is there a reason behind this, I mean, a technical problem? (I am not
Elena> familiar with the scenarion, sorry). Or, it has not been implemented
Elena> but it could be?

	There is no fundamental technical obstacle, but it is not
implemented now.  I can request the feature be added to the AIX Assembler,
but it is not going to be available on any timeframe necessary for the GCC
3.0 release.

	A feature supporting this extension also is not available in the
GNU Assembler.  It might be easier to get something into GNU as, but it is
not compatible with older versions of GNU as (can you say autoconf test
for a particular feature?).  And the assembly output will not be
compatible with the AIX Assembler.

	This does not seem like an important enough problem to break
compatibility with the AIX assembler and/or require the GNU Assembler for
any source code compiled with debugging enabled.

	The GNU Compiler cannot simply require an unimplemented feature in
the assembler without previously having the feature in the product plan
for the assembler.

David

Re: Limited success with 3.0 branch on AIX

[David Edelsohn]

	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?

	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.

David

Re: Limited success with 3.0 branch on AIX

[Kevin Buettner]

On May 16,  4:06pm, David Edelsohn wrote:

> 	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?

As noted in past email, generic_use_struct_convention() uses this
information.  But, after studying the code again, I've concluded that
the value that this function returns will be the same regardless of
whether "gcc2_compiled." is defined or not.

Also, we have the following comment from symtab.h:

    /* Version of GCC used to compile the function corresponding
       to this block, or 0 if not compiled with GCC.  When possible,
       GCC should be compatible with the native compiler, or if that
       is not feasible, the differences should be fixed during symbol
       reading.  As of 16 Apr 93, this flag is never used to distinguish
       between gcc2 and the native compiler.

       If there is no function corresponding to this block, this meaning
       of this flag is undefined.  */

    unsigned char gcc_compile_flag;

So, if this comment can be believed, gdb's behavior should be the same
regardless of whether or not "gcc2_compiled." is defined.

My conclusion is that GDB won't be hurt at all (for AIX on Power or
PowerPC) if "gcc2_compiled." is left undefined.

Kevin

Re: Limited success with 3.0 branch on AIX

[Stan Shebs]

Kevin Buettner wrote:
> 
>     /* Version of GCC used to compile the function corresponding
>        to this block, or 0 if not compiled with GCC.  When possible,
>        GCC should be compatible with the native compiler, or if that
>        is not feasible, the differences should be fixed during symbol
>        reading.  As of 16 Apr 93, this flag is never used to distinguish
>        between gcc2 and the native compiler.

(page page page...) My creaky and failing memory recalls configs
where GCC did not produce code that was 100% compatible with the
vendor compiler, for instance in the area of struct returns.  So GDB
needed to know which convention was in use, and in the absence of
better hints (such as when -g wasn't specified), the gcc2_compiled
symbol would get the info through.  (It matters for the non-debug
case because we may need to walk through non-debug frames to get to
the frames of interest.)

I think it's still possible to use GCC in a way that makes the
label necessary, for instance by using some of the more dubious
flags in some of the more obscure configs, but I doubt that PowerPC
is one of them.  I'd suggest blasting this old stuff anyway, adding
a cautionary note to the internals manual ("don't let the compiler
do this, ever" and reopening the issue afresh should it come up again.

Stan

Re: Limited success with 3.0 branch on AIX

[David Edelsohn]

>>>>> Stan Shebs writes:

Stan> I'd suggest blasting this old stuff anyway, adding
Stan> a cautionary note to the internals manual ("don't let the compiler
Stan> do this, ever" and reopening the issue afresh should it come up again.

	Are you suggesting removing the "gcc2_compiled." debugging symbol
from the AIX port, the PowerPC port, or all GCC ports?

Thanks, David

Re: Limited success with 3.0 branch on AIX

[Elena Zannoni]

There is another thread going on in the gdb-patches mailing list about this
very same topic:

http://sources.redhat.com/ml/gdb-patches/2001-05/msg00333.html

Elena


Kevin Buettner writes:
 > On May 16,  4:06pm, David Edelsohn wrote:
 > 
 > > 	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?
 > 
 > As noted in past email, generic_use_struct_convention() uses this
 > information.  But, after studying the code again, I've concluded that
 > the value that this function returns will be the same regardless of
 > whether "gcc2_compiled." is defined or not.
 > 
 > Also, we have the following comment from symtab.h:
 > 
 >     /* Version of GCC used to compile the function corresponding
 >        to this block, or 0 if not compiled with GCC.  When possible,
 >        GCC should be compatible with the native compiler, or if that
 >        is not feasible, the differences should be fixed during symbol
 >        reading.  As of 16 Apr 93, this flag is never used to distinguish
 >        between gcc2 and the native compiler.
 > 
 >        If there is no function corresponding to this block, this meaning
 >        of this flag is undefined.  */
 > 
 >     unsigned char gcc_compile_flag;
 > 
 > So, if this comment can be believed, gdb's behavior should be the same
 > regardless of whether or not "gcc2_compiled." is defined.
 > 
 > My conclusion is that GDB won't be hurt at all (for AIX on Power or
 > PowerPC) if "gcc2_compiled." is left undefined.
 > 
 > Kevin
 > 

Re: 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
 > 

Re: Limited success with 3.0 branch on AIX

[David Edelsohn]

>>>>> Elena Zannoni writes:

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

	Don't everyone answer at once!

	Avoiding gcc2_compiled altogether would seem best to me.  I defer
to the GDB developers whether this is correct.

	I am a bit concerned about removing gcc2_compiled on AIX and not
making this a broader policy across all targets because some dependency
could slip in.

	Instead of "gcc2_compiled", it seems better for GCC to utilize
whatever compiler version information or compiler-specific information is
allowed in the object format.  Is N_OPT really the standard?  Where do HP
and SGI and Intel and Greenhills and Metrowerks and other place their
version information?

David