[patch 00/12] entryval: Fix x86_64 <optimized out> parameters, virtual tail call frames

[patch 00/12] entryval: Fix x86_64 <optimized out> parameters, virtual tail call frames

[Jan Kratochvil]

Hi,

this is GDB side implementation of the DWARF-5.0 `entry values' extension:

Improving debug info for optimized away parameters
	http://gcc.gnu.org/wiki/summit2010?action=AttachFile&do=get&target=jelinek.pdf
GCC patch:
	[PATCH] Debug info extensions to support optimized out parameters
	http://gcc.gnu.org/ml/gcc-patches/2010-08/msg01475.html
currently on trunk (FSF gcc-4.7.0), not in any FSF gcc-4.6.x.  For Fedora
users it is backported in gcc-4.6.1-1.fc16.

It is targeted at improving backtraces of -O2 -g code; it has no effect for
-O0 -g code or for code without -g.  And the primary target is x86_64 with
parameters in registers which get usually lost very soon.  i386 with stack
passed parameters has them available during the whole function execution.

The features for GDB:

 * Reduce <optimized out> parameters on x86_64 (arches with parameters in
   registers)
   [ There was difficulty with Python interactive debugging on x86_64 where
     the `f' parameter is Python context and it is essential for debugging:
     #13  in PyEval_EvalFrameEx (f=<value optimized out>, throwflag=<value optimized out>) at /usr/src/debug/Python-2.7/Python/ceval.c:2552
     ->
     #13  in PyEval_EvalFrameEx (f=0x29aeb70, throwflag=0) at /home/jkratoch/redhat/fedora/python/f14/Python-2.7/Python/ceval.c:2552
   ]

 * Enable displaying paramname@entry - value the parameter had at the function
   entry
   [ "" is not much useful to see in `bt full' of GDB itself:
     #8  in execute_command (p=0x22b573b "", from_tty=1) at top.c:438
             p@entry = 0x22b5720 "maintenance internal-error "
     In this case there is also a local variable which shows the same info;
             line = 0x22b5720 "maintenance internal-error "
     in other apps there does not have to be such variable
   ]

 * Display virtual tail call frames (jmp instead of call at the end)
   [ PDF Figure 5 frame #6 is a virtual tail call frame ]

Besides the new supported syntax `paramname@entry' no new user interaction is
needed, everything just improves the user experience and makes -O2 -g
debugging like -O0 -g debugging.  In fact better thanks to the @entry values.

There are some further extension possibilities at least on the GDB side (such
as showing parameters which self tail calls which do not modify them etc.) and
I guess there may be more extensions possible also on the GCC side; but this
patchset gives at least the initial playground, also good enough for already
improving experience of direct debugging of production (-O2 -g) code.
Practical deployment should show the next direction of improvements.

The patches are available (merged only) in GIT for more convenience at:
	http://sourceware.org/gdb/wiki/ArcherBranchManagement
	archer-jankratochvil-entryval

No regressions on {x86_64,x86_64-m32,i686}-fedora16pre-linux-gnu.
Except for the last patch the intermediate patches do not have pre-compiled
testcase and they require gcc-4.7.0 and runtest flag COMPILE=1.


Thanks,
Jan

Re: [patch 00/12] entryval: Fix x86_64 <optimized out> parameters, virtual tail call frames

[Tom Tromey]

>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:

Jan> this is GDB side implementation of the DWARF-5.0 `entry values'
Jan> extension:

Thanks again for tackling this.

Jan> Besides the new supported syntax `paramname@entry' no new user
Jan> interaction is needed, everything just improves the user experience
Jan> and makes -O2 -g debugging like -O0 -g debugging.  In fact better
Jan> thanks to the @entry values.

I read all the patches and sent replies where I thought they were
warranted.  In particular I think patches 1, 3, 8, 9, and 12 are ok
without additional comment.

I noticed that you did not patch the DWARF->AX translator.  If you'd
rather not do this, or if it isn't possible, that is fine; the
translator is already incomplete, simply because AX is not expressive
enough.

Tom

Re: [patch 00/12] entryval: Fix x86_64 <optimized out> parameters, virtual tail call frames

[Jan Kratochvil]

On Tue, 19 Jul 2011 18:26:03 +0200, Tom Tromey wrote:
> In particular I think patches 1, 3, 8, 9, and 12 are ok without additional
> comment.

OK, thanks.


> I noticed that you did not patch the DWARF->AX translator.  If you'd
> rather not do this, or if it isn't possible, that is fine; the
> translator is already incomplete, simply because AX is not expressive
> enough.

It just "safely" says:
      DWARF operator DW_OP_GNU_entry_value cannot be translated to an agent expression

I have seen more opcodes not implemented so I did not feel so guilty.

It may have been discussed - it is not in `(gdb)Rationale' - why isn't AX at
least derived from DWARF?  But I guess the answer is the part of DWARF
expressions compatible with `(gdb)Rationale' --- the AX requirements - is
negligibly small.


Thanks,
Jan

Re: [patch 00/12] entryval: Fix x86_64 <optimized out> parameters, virtual tail call frames

[Tom Tromey]

>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:

Jan> It may have been discussed - it is not in `(gdb)Rationale' - why
Jan> isn't AX at least derived from DWARF?  But I guess the answer is
Jan> the part of DWARF expressions compatible with `(gdb)Rationale' ---
Jan> the AX requirements - is negligibly small.

I don't know, but we've collected a number of issues with AX as it now
stands.  These aren't merely theoretical, either, but problems with code
actually generated by GCC.  Those missing opcodes aren't missing out of
laziness, but rather because for the most part they aren't efficiently
implementable.  (One exception is the typed DWARF extension -- but we
could only handle integral types, which is probably not an interesting
subset.)

AX needs some big upgrades, or maybe an "AX 2.0" explicitly based on
DWARF.  I think the blocker here is that we (Red Hat) are on the cutting
edge for compilers and debuginfo, but don't currently have many users
using AX; but shops where the users are using AX are often (just
guessing) a few compiler revisions behind -- so nobody has really felt
the pain yet.


A related problem closer to home is that watchpoints don't respect
location lists.  Whoops.  I don't have a test case but I think one
should be constructible.  (I consider this related because it is another
spot where DWARF expressiveness has not propagated throughout GDB.)

Tom

Re: [patch 00/12] entryval: Fix x86_64 <optimized out> parameters, virtual tail call frames

[Jan Kratochvil]

On Tue, 19 Jul 2011 19:52:25 +0200, Tom Tromey wrote:
> AX needs some big upgrades, or maybe an "AX 2.0" explicitly based on
> DWARF.

OK, thanks for the info.


> A related problem closer to home is that watchpoints don't respect
> location lists.

I at least filed it some time ago.
	hardware watchpoint missed for -O2 -g inferior
	http://sourceware.org/bugzilla/show_bug.cgi?id=11613


Jan

Re: [patch 00/12] entryval: Fix x86_64 <optimized out> parameters, virtual tail call frames

[Tom Tromey]

Tom> AX needs some big upgrades, or maybe an "AX 2.0" explicitly based on
Tom> DWARF.

Jan> OK, thanks for the info.

I forgot to mention, I think this is all in bugzilla, e.g.:

http://sourceware.org/bugzilla/show_bug.cgi?id=11662
http://sourceware.org/bugzilla/show_bug.cgi?id=12769

Tom

obsolete: [patch 00/12] entryval: Fix x86_64 <optimized out> parameters, virtual tail call frames

[Jan Kratochvil]

obsoleted by:
	[patch 00/12] entryval#2: Fix x86_64 <optimized out> parameters, virtual tail call frames
	http://sourceware.org/ml/gdb-patches/2011-09/msg00222.html