[lldb-dev] [Bug 36870] New: x86_64 ABI only takes doesn't consult C++ info in computing return types

2018-03-22 Thread via lldb-dev
https://bugs.llvm.org/show_bug.cgi?id=36870

Bug ID: 36870
   Summary: x86_64 ABI only takes doesn't consult C++ info in
computing return types
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: jing...@apple.com
CC: llvm-b...@lists.llvm.org

Created attachment 20105
  --> https://bugs.llvm.org/attachment.cgi?id=20105&action=edit
Example file showing a case where we get the return wrong.

Build the attached notright.cpp and do:

 > lldb notright
(lldb) b s -p "Set a breakpoint here"
Breakpoint 1: where = notright`takeS(S) + 25 at notright.cpp:10, address =
0x00010e19
(lldb) run
Process 35604 launched: '/tmp/notright' (x86_64)
Process 35604 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
frame #0: 0x00010e19 notright`takeS(S) at notright.cpp:10
   7{
   8  S ret_val = inVal;
   9  ret_val.ivar = 30;
-> 10 return ret_val;   // Set a breakpoint here
  ^
   11   }
   12   
   13   int
Target 0: (notright) stopped.
(lldb) fin
Process 35604 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = step out
Return value: (S) $0 = {
  ivar = -272632024
}

frame #0: 0x00010ea4 notright`main at notright.cpp:17
   14   main()
   15   {
   16 S inVal, outVal;
-> 17 outVal = takeS(inVal);
   ^
   18   
   19 return 0;
   20   }
Target 0: (notright) stopped.

Note that the return value was not calculated correctly.  The struct is in fact
small enough and correctly aligned so by the simple Itanium ABI it should have
gotten passed in registers, but C++ for its own reasons decided to pass it in
memory instead.  We have to dig more information out of the C++ type to figure
out these cases.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


[lldb-dev] [Bug 36871] New: Wrong handling of DW_OP_deref with global variables

2018-03-22 Thread via lldb-dev
https://bugs.llvm.org/show_bug.cgi?id=36871

Bug ID: 36871
   Summary: Wrong handling of DW_OP_deref with global variables
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: swiftix...@gmail.com
CC: llvm-b...@lists.llvm.org

Created attachment 20106
  --> https://bugs.llvm.org/attachment.cgi?id=20106&action=edit
Reduced test-case

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.

The code for creating logical variables looks roughly like:

llvm::SmallVector 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.
ops.push_back(llvm::dwarf::DW_OP_deref);
// Add a constant offset to the value of the global variable.
ops.push_back(llvm::dwarf::DW_OP_constu);
ops.push_back(offset);
ops.push_back(llvm::dwarf::DW_OP_plus);
llvm::DIExpression *DIexpr{nullptr};
auto *DIE = DIBuilder_->createExpression(ops);
auto *GVE = DIBuilder_->createGlobalVariableExpression(
cu, name, "", file, 0, type,
/* isLocalToUnit */ false, DIE);
// Add GVE as debug info to BaseAddress.
baseAddress->addDebugInfo(GVE);


GDB does not have the issue. So, it seems like a bug in LLDB.

See the following thread for a discussion of the issue:
https://groups.google.com/forum/#!topic/llvm-dev/TIkoLc04zSQ

The attached lldb_bug.ll file contains a reduced example. It has a global
variable "baseAddress", which contains a pointer to a memory block. And it
defines a logical global variable "var1" by means of debug information, which
should be at address (value of (baseAddress) + 0).

I used the following commands to produce the executable:
llvm-as lldb_bug.ll -f
llc -filetype=obj lldb_bug.bc
clang lldb_bug.o -o lldb_bug

Then you simply start LLDB with lldb_bug as executable.
If you then try this command:
p &var1
you'll see something different from the expected 0.

Most likely, the problem is that DW_OP_deref is not handled correctly when
applied to global variables or something like this.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev