Re: Contributing LLVM.org patches to gud.el

[Daniel Colascione <dancol@dancol.org>]

[-- Attachment #1: Type: text/plain, Size: 1651 bytes --]

On 02/12/2015 08:26 AM, Eli Zaretskii wrote:
>> Date: Wed, 11 Feb 2015 18:07:42 +0200
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: dancol@dancol.org, dak@gnu.org, emacs-devel@gnu.org
>>
>>> From: "Stephen J. Turnbull" <stephen@xemacs.org>
>>> Cc: David Kastrup <dak@gnu.org>,
>>>     Eli Zaretskii <eliz@gnu.org>,
>>>     emacs-devel@gnu.org
>>> Date: Wed, 11 Feb 2015 22:22:24 +0900
>>>
>>> Eli mentioned DWARF 2.  The manual for GCC 4.8.4 says:
>>>
>>>     -g
>>>     Produce debugging information in the operating system's native format
>>>     (stabs, COFF, XCOFF, or DWARF 2). GDB can work with this debugging
>>>     information.
>>>
>>> Later there is an option for specifying the version of DWARF, which
>>> cautions that use of DWARF 4 "may require gdb 7 and
>>> -fvar-tracking-assignments".  I'll have to try that.
> 
> AFAIU, -fvar-tracking-assignments is automatically turned on when
> compiling an optimized program.

Maybe it's better these days. In some cases, we really can't reconstruct
values. Consider something like this:

  unsigned x = foo();
  unsigned y = x / 2;

If y == 4, we don't know whether x was 8 or 9.

But that's not the case I've seen most. When debugging optimized code,
though, I've run into far more annoying situations. Consider this code:

void
foo(void* context)
{
  struct value* c = context;
  bar(c);
}

Say I'm broken into the program just before the call to bar and I want
to inspect some field of c. I should be able to print c->field, right?
Except GDB tells me that c is <optimized out>, even though context is
right there and contains the same bits!



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]