DWARF parser: <DW_OP_piece for offset 4 but top of stack is of size 8>

[llvmbot]

Bugzilla Link	39798
Version	7.0
OS	All
Attachments	testcase
Reporter	LLVM Bugzilla Contributor

Extended Description

(lldb) b main
Breakpoint 1: where = a.out`main + 4 at a-prepro.c:2303:5, address = 0x0000000100000b44
(lldb) r
Process 81971 launched: '/Users/davide/work/llvm-project-20170507/build-rel/bin/a.out' (x86_64)
a.out was compiled with optimization - stepping may behave oddly; variables may not be available.
Process 81971 stopped

• thread #​1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
  frame #​0: 0x0000000100000b44 a.out`main(argc=1, argv=0x00007ffeefbffaf0) at a-prepro.c:2303:5 [opt]
  2300 int print_hash_value = 0;
  2301 if (argc == 2 && strcmp(argv[1], "1") == 0) print_hash_value = 1;
  2302 platform_main_begin();
  -> 2303 func_1();
  2304 for (i = 0; i < 8; i++)
  2305 {
  2306 csmith_sink_ = g_8[i];
  (lldb) frame var g_88
  (S0 [5]) g_88 = <DW_OP_piece for offset 4 but top of stack is of size 108>

(lldb) p g_88
error: Couldn't materialize: couldn't get the value of variable g_88: DW_OP_piece for offset 4 but top of stack is of size 108
error: errored out in DoExecute, couldn't PrepareToExecuteJITExpression

$ ./clang a-prepro.c -g -O1 -Wno-everything

[llvmbot]

Here's a reduced test case.

$ cat a.c
struct a {
unsigned f0;
short f1;
unsigned f2;
int f3;
short f4;
unsigned f5;
};
short b, f;
int g;
void c(struct a e) {}
short d() {
struct a l_28 = {2804376675, 1, 4294967295, 3, 52490, 4294967293};
b = 9;
for (; b;) {
c((g, l_28));
return f;
}
return patatino(l_28.f1);
}
int main() { d(); }

$ cat outer.c
short patatino(short f) { return f; }

$ clang a.c outer.c -g -O1

$ lldb
[...]
(lldb) br set -p patatino
(lldb) frame var
(a) l_28 = <DW_OP_piece for offset 4 but top of stack is of size 8>

[llvmbot]

I also see this with Clang and GCC on this code:

#include <stdio.h>

struct Point {
int x;
int y;
};

void DoIt(Point* p) {
printf("%d, %d\n", p->x, p->y);
}

int main(int argc, char **argv) {
Point p{.x = argc * 100, .y = argc};
DoIt(&p);
return 0;
}

Compile with -O2 and print "p". Clang produces the expression for "p"

DW_OP_reg4 RSI, DW_OP_piece 0x4, DW_OP_reg1 RDX, DW_OP_piece 0x4

[llvmbot]

Hi!

This issue may be a good introductory issue for people new to working on LLVM. If you would like to work on this issue, your first steps are:

1. Assign the issue to you.
2. Fix the issue locally.
3. Run the test suite locally.
   3.1) Remember that the subdirectories under test/ create fine-grained testing targets, so you can
   e.g. use make check-clang-ast to only run Clang's AST tests.
4. Create a git commit
5. Run git clang-format HEAD~1 to format your changes.
6. Submit the patch to Phabricator.
   6.1) Detailed instructions can be found here

For more instructions on how to submit a patch to LLVM, see our documentation.

If you have any further questions about this issue, don't hesitate to ask via a comment on this Github issue.

@llvm/issue-subscribers-good-first-issue

[curiouserrandy]

I can't assign this bug to myself, so just leaving a note here that I'm going to take a look at it. I'll leave another comment if/when I stop working on it.

[curiouserrandy]

Quick notes for checkpointing purposes:

• I've tried to reproduce this bug in arm64 and x86. In neither case does it reproduce as described above.
• Arm64 (clang apple default installed Apple 14.0.3, lldb built from commit 22f81b4) using a-prepro.c produces a new error:

   error: Couldn't materialize: couldn't get the value of variable g_88: failed to read memory DW_OP_piece(4) from file address 0x100008068
   error: errored out in DoExecute, couldn't PrepareToExecuteJITExpression

• x86 (clang and lldb both installed through yum package manager at 15.0.7) using a-prepro.c doesn't produce an error, but does produce what appears to be incorrect output:

$ lldb a.out
(lldb) target create "a.out"
Current executable set to '/home/ec2-user/a.out' (x86_64).
(lldb) b main
b main
Breakpoint 1: where = a.out'main + 4 [inlined] func_1 at a-prepro.c:2189:15, address = 0x0000000000401134
(lldb) r
r
Process 26551 launched: '/home/ec2-user/a.out' (x86_64)
Process 26551 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
    frame #0: 0x0000000000401134 a.out`main [inlined] func_1 at a-prepro.c:2189:15
   2186	    int32_t *l_33 = &g_9[4];
   2187	    int16_t **l_50 = (void*)0;
   2188	    uint32_t l_51 = 0xDBE4212CL;
-> 2189	    uint16_t *l_90 = &g_69;
    	              ^
   2190	    uint16_t **l_89 = &l_90;
   2191	    int32_t l_100[4];
   2192	    uint8_t l_102 = 0UL;
(lldb) p g_88
p g_88
(S0[5]) $0 = {
  [0] = (f0 = 0, f1 = 0, f2 = 0, f3 = 0, f4 = 0, f5 = 0, f6 = '\0', f7 = 0, f8 = 0)
  [1] = (f0 = 0, f1 = 0, f2 = 0, f3 = 0, f4 = 0, f5 = 0, f6 = '\0', f7 = 0, f8 = 0)
  [2] = (f0 = 0, f1 = 0, f2 = 0, f3 = 0, f4 = 0, f5 = 1, f6 = '\xa7', f7 = 0, f8 = 0)
  [3] = (f0 = 0, f1 = 0, f2 = 0, f3 = 0, f4 = 0, f5 = 0, f6 = '\0', f7 = 0, f8 = 0)
  [4] = (f0 = 0, f1 = 0, f2 = 0, f3 = 0, f4 = 0, f5 = 0, f6 = '\0', f7 = 0, f8 = 0)
}
(lldb) 

As the definition of the g_88 variable in the example file is:

static struct S0 g_88[5] = {{0x0258L,0L,0xEE239CA8L,0x0D89L,0x2C1F8D07FB14099FLL,1L,0xA7L,0x86F5C60DL,1UL},{0x0258L,0L,0xEE239CA8L,0x0D89L,0x2C1F8D07FB14099FLL,1L,0xA7L,0x86F5C60DL,1UL},{0x0258L,0L,0xEE239CA8L,0x0D89L,0x2C1F8D07FB14099FLL,1L,0xA7L,0x86F5C60DL,1UL},{0x0258L,0L,0xEE239CA8L,0x0D89L,0x2C1F8D07FB14099FLL,1L,0xA7L,0x86F5C60DL,1UL},{0x0258L,0L,0xEE239CA8L,0x0D89L,0x2C1F8D07FB14099FLL,1L,0xA7L,0x86F5C60DL,1UL}};

Possibly directions forward I'm considering are debugging the arm64 error, debugging the x86 error, and attempting to build the old version of clang and lldb to make sure I'm not doing something wrong in trying to reproduce the error. My primary motivation for working on this bug is learning the code and the process, which probably argues for debugging the arm64 error. That judgement is based in part on my sense that no one really cares about this bug--if that's wrong, feel free to let me know :-)

[curiouserrandy]

Update on progress: This looks to me as if DWARFExpression::Evaluate() simply doesn't handle the case of DW_OP_piece referring to DW_OP_addr that point into files. The clang DWARF output in question looks like:

0x0000008d:   DW_TAG_variable [9]   (0x0000000b)
               DW_AT_name [DW_FORM_strp]	( .debug_str[0x0000010f] = "g_88")
                DW_AT_type [DW_FORM_ref4]	(cu + 0x00b2 => {0x000000b2} "S0[5]")
                DW_AT_decl_file [DW_FORM_data1]	("/Users/randy/Google Drive/Work/LLVM/bug39145/a-prepro.c")
                DW_AT_decl_line [DW_FORM_data2]	(2153)
                DW_AT_location [DW_FORM_exprloc]	(DW_OP_piece 0x68, DW_OP_addr 0x100008068, DW_OP_piece 0x4, DW_OP_addr 0x10000806c, DW_OP_piece 0x1)

I interpret (based on reading the spec) the DW_AT_location line as meaning "0x68 bytes optimized out, 4 bytes @ addr 0x100008068, 1 byte @ addr 0x10000806c". The code that is producing the error is:

          switch (curr_piece_source_value_type) {
...
          case Value::ValueType::FileAddress:
          case Value::ValueType::HostAddress:
            if (error_ptr) {
              lldb::addr_t addr = curr_piece_source_value.GetScalar().ULongLong(
                  LLDB_INVALID_ADDRESS);
              error_ptr->SetErrorStringWithFormat(
                  "failed to read memory DW_OP_piece(%" PRIu64
                  ") from %s address 0x%" PRIx64,
                  piece_byte_size, curr_piece_source_value.GetValueType() ==
                                           Value::ValueType::FileAddress
                                       ? "file"
                                       : "host",
                  addr);
            }
            return false;

I may be missing something, but I read that as "Not Implemented" :-}.

I've added the code to do the file to handle loads of type FileAddress, which appears to solve this bug. I plan to also handle code to handle loads of type HostAddress, then (the hard part) add tests.

Comments on this plan welcome but not requested.