This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [vta->trunk] VTA merge
- From: Jakub Jelinek <jakub at redhat dot com>
- To: David Edelsohn <dje dot gcc at gmail dot com>
- Cc: "Joseph S. Myers" <joseph at codesourcery dot com>, Jack Howarth <howarth at bromo dot med dot uc dot edu>, Steven Bosscher <stevenb dot gcc at gmail dot com>, Tom Tromey <tromey at redhat dot com>, Richard Guenther <richard dot guenther at gmail dot com>, Alexandre Oliva <aoliva at redhat dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 31 Aug 2009 09:10:50 +0200
- Subject: Re: [vta->trunk] VTA merge
- References: <303e1d290908301344k6c48e4e8pd754a73df7eae25@mail.gmail.com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Sun, Aug 30, 2009 at 04:44:34PM -0400, David Edelsohn wrote:
> Does this mean that older versions of GDB will not work with the new debugging
> information? I do not expect older versions of GDB to use the additional
> information, but I expected that they at least would ignore it and
> work as before.
With the GDB versions I've tried, GDB just won't be able to print the
variables that use the new operations in the location lists, like:
(gdb) p j
Unhandled dwarf expression opcode 0x9f
(gdb) p k
$1 = 6
Without VTA it would print:
$1 = <value optimized out>
instead. That's both with
GNU gdb (GDB) Fedora (6.8.50.20090302-37.fc11)
and
GNU gdb (GDB) 6.8.50.20090723-cvs
> What is the effect of VTA on non-Dwarf debugging targets, such as AIX, which
> uses stabs-like debugging. Again, I do not expect the additional information
> to be recorded in stabs, but I do expect stabs debugging to continue to work.
It should have no effect on non-DWARF debugging targets. Similarly to
-fvar-tracking, it defaults to off on those targets, and even if you
explicitely enable the var tracking resp. var assignments tracking, it will
be tracked and then completely ignored during the debuginfo output.
Jakub