Re: Limited success with 3.0 branch on AIX

[David Edelsohn <dje@watson.ibm.com>]

	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