This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Limited success with 3.0 branch on AIX


David Edelsohn writes:
 > 	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.

Yes, gdb would need to be made a little smarter.

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

Right. And violates the xcoff standard.

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

Ah, I see, there is no way of putting that info where it should
be. I agree, but from the gdb standpoint it is the same as putting the info
in a global symbol entry. Gdb would have to process that class in an ad hoc
way. It seems to me that associating the info with a file entity is closer
to the real purpose of gcc2_compiled. But I could be convinced otherwise.

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

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

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

Thanks for looking into this.

 > David
 > 

Elena


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]