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:24:23 -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><200105161814.OAA25626@makai.watson.ibm.com>
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
>