[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Contributing LLVM.org patches to gud.el

From: Daniel Colascione
Subject: Re: Contributing LLVM.org patches to gud.el
Date: Thu, 12 Feb 2015 09:42:46 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0

On 02/12/2015 08:26 AM, Eli Zaretskii wrote:
>> Date: Wed, 11 Feb 2015 18:07:42 +0200
>> From: Eli Zaretskii <address@hidden>
>> Cc: address@hidden, address@hidden, address@hidden
>>> From: "Stephen J. Turnbull" <address@hidden>
>>> Cc: David Kastrup <address@hidden>,
>>>     Eli Zaretskii <address@hidden>,
>>>     address@hidden
>>> 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:

foo(void* context)
  struct value* c = context;

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: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]