[Dwarf-Discuss] Does gcc optimization impacts retriving Dwarf information?

[M. Mohan Kumar]

On Thu, May 28, 2009 at 08:55:31AM -0700, Michael Eager wrote:
> Frank Ch. Eigler wrote:
>> Hi -
>>
>> On Thu, May 28, 2009 at 02:57:08AM -0700, Michael Eager wrote:
>>> [...]
>>>> This problem (unable to retrieve variable values) raises two questions:
>>>> 1. Does it mean that compiling with -O2 option removes some of the
>>>> information needed by DWARF library functions?
>>> [...]  DIEs for variables which do not have DW_AT_location
>>> attributes do not have physical locations.  Your crash dump utility
>>> should not attempt to find the locations or print the values for
>>> these variables.

Hi Eager,

We checked the objdump of vmlinux and we observed:

linux-2.6.27.orig/arch/powerpc/platforms/pseries/setup.c:484
  80352 c00000000003b06c:       a3 ed 00 0a     lhz     r31,10(r13)

and the corresponding C source is:
482 static void pseries_dedicated_idle_sleep(void)
483 {
484         unsigned int cpu = smp_processor_id();

So the variable 'cpu' is placed in the register r31 and whenever cpu needs
to be accessed, r31 was used and not the value of variable cpu in the
instruction. So is it a problem with GCC generating dwarf information?


>>
>> That's all true in the abstract, but modern gcc has been known to
>> abscond with variable location data even for values that are
>> live/recomputable.  This is the main reason why the VTA (and
>> debuglocus and other) gcc projects are under way -- to represent the
>> maximum possible conceptual data, despite -O2 etc.

Frank, Will VTA/debuglocus have the dwarf compatibility (i.e. it does not
need modification to existing applications using libdwarf APIs)?

When can we expect this features (VTA/debuglocus) integrated into mainline
gcc?

Regards,
M. Mohan Kumar