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: David Edelsohn <dje at watson dot ibm dot com>
- Subject: Re: Limited success with 3.0 branch on AIX
- From: Elena Zannoni <ezannoni at cygnus dot com>
- Date: Wed, 16 May 2001 15:20:39 -0400
- Cc: Elena Zannoni <ezannoni at cygnus dot com>, 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
- References: <ezannoni@cygnus.com><15105.47488.332324.391947@kwikemart.cygnus.com><200105161745.NAA29020@makai.watson.ibm.com>
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