[llvm-dev] Question about debug information for global variables

Roman Levenstein via llvm-dev llvm-dev at lists.llvm.org
Thu Mar 22 18:26:27 PDT 2018


On Thu, Mar 22, 2018 at 5:15 PM, Davide Italiano <davide at freebsd.org> wrote:
> On Thu, Mar 22, 2018 at 5:13 PM, Roman Levenstein via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>> On Thu, Mar 22, 2018 at 4:51 PM, Adrian Prantl <aprantl at apple.com> wrote:
>>>
>>>
>>>> On Mar 22, 2018, at 4:47 PM, Roman Levenstein <romixlev at gmail.com> wrote:
>>>>
>>>> Adrian,
>>>>
>>>> Thanks for a quick reply!
>>>>
>>>> On Thu, Mar 22, 2018 at 4:22 PM, Adrian Prantl <aprantl at apple.com> wrote:
>>>>>
>>>>>
>>>>>> On Mar 22, 2018, at 4:08 PM, Roman Levenstein <romixlev at gmail.com> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I'm trying to achieve the following:
>>>>>>
>>>>>> - I have a global variable BaseAddress that holds the base address of
>>>>>> a contiguous dynamically allocated memory block.
>>>>>>
>>>>>> - I have a number of logical variables of different types that are
>>>>>> mapped on certain address ranges inside the memory block pointed to by
>>>>>> BaseAddress. The offset and the size of each such logical variable
>>>>>> inside the memory block are known constants.
>>>>>>
>>>>>> - I'd like to make it possible to access these logical variables
>>>>>> inside the debugger as if they are normal global variables.
>>>>>>
>>>>>> My idea was to create the debug information for each of these logical
>>>>>> variables by using DIBuilder::createGlobalVariableExpression called
>>>>>> GVE and provide a DIExpression called DIE that should basically take
>>>>>> the value of the global variable GVE is added to, i.e. the value of
>>>>>> BaseAddress, and add a constant offset corresponding to the logical
>>>>>> variable. This should be the address of the logical variable.
>>>>>>
>>>>>> So, the DIExpression  DIE would look something like:
>>>>>> DW_OP_deref, DW_OP_constu, offset, DW_OP_plus
>>>>>>
>>>>>> But this does not work. I tried the variants with and without
>>>>>> DW_OP_deref, but I always get the same wrong result when I test with
>>>>>> LLDB. The offset is always added to the address of BaseAddress and not
>>>>>> to its value.
>>>>>
>>>>> Can you share the final expression as printed by llvm-dwarfdump?
>>>>
>>>> This is what I see printed by llvm-dwarfdump using the command-line:
>>>> llvm-dwarfdump -verify-debug-info -debug-dump=all myobjectfile.o
>>>>
>>>>
>>>> The DW_AT_location values are different:
>>>>
>>>> With deref:
>>>> 0x00000032:   DW_TAG_variable [2]
>>>>                DW_AT_name [DW_FORM_strp]       (
>>>> .debug_str[0x0000001d] = "var1")
>>>>                DW_AT_type [DW_FORM_ref4]       (cu + 0x0049 => {0x00000049})
>>>>                DW_AT_external [DW_FORM_flag_present]   (true)
>>>>                DW_AT_location [DW_FORM_exprloc]        (<0xd> 03 b0
>>>> 2e 00 00 00 00 00 00 06 10 00 22 )
>>>>
>>>>
>>>> Without deref:
>>>> 0x00000032:   DW_TAG_variable [2]
>>>>                DW_AT_name [DW_FORM_strp]       (
>>>> .debug_str[0x0000001d] = "var1")
>>>>                DW_AT_type [DW_FORM_ref4]       (cu + 0x0048 => {0x00000048})
>>>>                DW_AT_external [DW_FORM_flag_present]   (true)
>>>>                DW_AT_location [DW_FORM_exprloc]        (<0xc> 03 a0
>>>> 2e 00 00 00 00 00 00 10 00 22 )
>>>>
>>>> Unfortunately, the llvm-dwarfdump output is not very descriptive when
>>>> it comes to expressions.
>>>
>>> You might want to use one built from current llvm.org trunk, it can now. Actually, would you mind doing that? I'd be curious as to what the first couple of bytes decode to.
>>>
>>
>> With deref:
>> 0x00000032:   DW_TAG_variable
>>                 DW_AT_name      ("var1")
>>                 DW_AT_type      (cu + 0x0049 "int[]")
>>                 DW_AT_external  (true)
>>                 DW_AT_location  (DW_OP_addr 0x2eb0, DW_OP_deref,
>> DW_OP_constu 0x0, DW_OP_plus)
>>
>> Without deref:
>> 0x00000032:   DW_TAG_variable
>>                 DW_AT_name      ("var1")
>>                 DW_AT_type      (cu + 0x0048 "int[]")
>>                 DW_AT_external  (true)
>>                 DW_AT_location  (DW_OP_addr 0x2ea0, DW_OP_constu 0x0,
>> DW_OP_plus)
>>
>>>>
>>>> In LLVM IR, it is more understandable:
>>>>
>>>> With deref:
>>>> !28 = !DIExpression(DW_OP_deref, DW_OP_constu, 2000, DW_OP_plus)
>>>>
>>>> Without deref:
>>>> !28 = !DIExpression(DW_OP_constu, 2000, DW_OP_plus)
>>>>
>>>>>>
>>>>>> The code for creating logical variables looks roughly like:
>>>>>>
>>>>>>   llvm::SmallVector<uint64_t, 4> ops;
>>>>>>   size_t offset = getOffset(logicalVariable);
>>>>>>   // Get the value of the global variable that contains a pointer to
>>>>>> the memory block.
>>>>>>   // NOTE: Even if DW_OP_deref is omitted, the results under LLDB
>>>>>> are the same.
>>>>>
>>>>> Have you considered that this might be a bug in LLDB? You really shouldn't get the same result with and without the DW_OP_deref (unless you are pointing to a self-referential pointer :-)
>>>>
>>>> Yes, I was wondering if it could be an LLDB bug, because I'd also
>>>> expect different results.
>>>>
>>>> That being said, does the overall approach I outlined seem correct?
>>>> I.e. should it be possible in principle to express the logical global
>>>> variables using the approach I outlined?
>>>
>>> The general approach seems fine to me. It should be fairly straightforward to debug this in LLDB's DWARF expression handler.
>>
>> I just tried with GDB. And GDB works fine with the DW_OP_deref
>> version. So, it is definitely a bug in LLDB.
>>
>
> Can you report the bug with a test case? Possibly reduced?

Sure.  https://bugs.llvm.org/show_bug.cgi?id=36871

-Roman

>
> Thanks,
>
> --
> Davide


More information about the llvm-dev mailing list