This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Limited success with 3.0 branch on AIX
- To: Elena Zannoni <ezannoni at cygnus dot com>
- Subject: Re: Limited success with 3.0 branch on AIX
- From: David Edelsohn <dje at watson dot ibm dot com>
- Date: Wed, 16 May 2001 13:45:53 -0400
- cc: Kevin Buettner <kevinb at cygnus dot com>, "Zack Weinberg" <zackw at Stanford dot EDU>, Matthew Conway <matt_conway at i2 dot com>, Mark Mitchell <mark at codesourcery dot com>, gcc-patches at gcc dot gnu dot org, gdb at sources dot redhat dot 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