[lldb-dev] Classes inheriting from RegisterContextDarwin_arm, and __APPLE__
The implementation of RegisterContextDarwin_arm is surrounded by #if defined(__APPLE__). Some other files define subclasses, e.g. RegisterContextDarwin_arm_Mach in ObjectFileMachO.cpp, that are built on non-apple machines. This seems... confusing, and causes me some problems trying to do dynamic linking. Is there something wrong here, or should I just avoid doing that :-) Cheers, Sam ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 31212] New: LLDB steps incorrectly for binaries compiled using GCC 6.2 on Ubuntu 16.10
https://llvm.org/bugs/show_bug.cgi?id=31212
Bug ID: 31212
Summary: LLDB steps incorrectly for binaries compiled using GCC
6.2 on Ubuntu 16.10
Product: lldb
Version: 3.9
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-dev@lists.llvm.org
Reporter: eldar.abusali...@jetbrains.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified
Step-over and step-in skip source lines and behave more like step-out for code
compiled on Ubuntu 16.10 using GCC 6.2, which by default compiles with -pie.
Everything works correctly when using -fno-pie explicitly. The weird thing is,
everything also works fine when compiling on Ubuntu 16.04 using GCC 6.2 from
ppa:ubuntu-toolchain-r/test.
The issue is also reproducible with binaries compiled on Ubuntu 16.10 using GCC
6.2 which are then debugged on another system, like Ubuntu 16.04.
Source code:
#include
void printHello() {
std::cout << "Hello, World! from function" << std::endl;
std::cout << "Hello, World! from function" << std::endl;
std::cout << "Hello, World! from function" << std::endl;
}
int main() {
printHello();
std::cout << "Hello, World! from main()" << std::endl;
std::cout << "Hello, World! from main()" << std::endl;
std::cout << "Hello, World! from main()" << std::endl;
return 0;
}
Debug session:
$ lldb ClionProjects/bug_test/cmake-build-debug/bug_test
Traceback (most recent call last):
File "", line 1, in
ImportError: No module named lldb.embedded_interpreter
(lldb) target create "ClionProjects/bug_test/cmake-build-debug/bug_test"
Current executable set to
'ClionProjects/bug_test/cmake-build-debug/bug_test' (x86_64).
(lldb) b main.cpp:10
Breakpoint 1: where = bug_test`main + 4 at main.cpp:10, address =
0x0993
(lldb) r
Process 2545 launched:
'/home/user/ClionProjects/bug_test/cmake-build-debug/bug_test' (x86_64)
Process 2545 stopped
* thread #1: tid = 2545, 0x4993 bug_test`main + 4 at
main.cpp:10, name = 'bug_test', stop reason = breakpoint 1.1
frame #0: 0x4993 bug_test`main + 4 at main.cpp:10
7 }
8
9 int main() {
-> 10 printHello();
11 std::cout << "Hello, World! from main()" << std::endl;
12 std::cout << "Hello, World! from main()" << std::endl;
13 std::cout << "Hello, World! from main()" << std::endl;
(lldb) s
Process 2545 stopped
* thread #1: tid = 2545, 0x4914 bug_test`printHello() + 4 at
main.cpp:4, name = 'bug_test', stop reason = step in
frame #0: 0x4914 bug_test`printHello() + 4 at main.cpp:4
1 #include
2
3 void printHello() {
-> 4 std::cout << "Hello, World! from function" << std::endl;
5 std::cout << "Hello, World! from function" << std::endl;
6 std::cout << "Hello, World! from function" << std::endl;
7 }
(lldb) s
Hello, World! from function
Hello, World! from function
Hello, World! from function
Process 2545 stopped
* thread #1: tid = 2545, 0x4998 bug_test`main + 9 at
main.cpp:11, name = 'bug_test', stop reason = step in
frame #0: 0x4998 bug_test`main + 9 at main.cpp:11
8
9 int main() {
10 printHello();
-> 11 std::cout << "Hello, World! from main()" << std::endl;
12 std::cout << "Hello, World! from main()" << std::endl;
13 std::cout << "Hello, World! from main()" << std::endl;
14 return 0;
(lldb) s
Hello, World! from main()
Hello, World! from main()
Hello, World! from main()
Process 2545 stopped
* thread #1: tid = 2545, 0x776a93f1 libc.so.6`__libc_start_main +
241, name = 'bug_test', stop reason = step in
frame #0: 0x776a93f1 libc.so.6`__libc_start_main + 241
libc.so.6`__libc_start_main:
-> 0x776a93f1 <+241>: movl %eax, %edi
0x776a93f3 <+243>: callq 0x776c3320; exit
0x776a93f8 <+248>: xorl %eax, %eax
0x776a93fa <+250>: jmp0x776a9337; <+55>
(lldb)
--
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
Re: [lldb-dev] Refactoring in LLDB Windows Plugin
What would it take to make it so that local and remote process plugins use the same exact interface? I mean in theory they're doing the same thing, just on a different machine. If they shared an identical interface then you could hook the lldb-server up to it and it would work either locally or remotely. What was the original motivation for having the api design of remote and local process plugins diverge? On Mon, Nov 28, 2016 at 12:56 PM Adrian McCarthy via lldb-dev < lldb-dev@lists.llvm.org> wrote: > I have no objection to moving in that direction (enabling remote > debugging). Zach just pointed out that we'd first have to port lldb-server > to Windows. Offhand, I don't know how much of an effort that would be. > > In the near-term, I'm focused on postmortem debugging, so this wouldn't be > a priority for me for a while. > > The "unfactoring" I mentioned in this email is essentially done, though > I'm planning to move some files to eliminate an unnecessary subdirectory > from the source paths. > > On Mon, Nov 28, 2016 at 12:43 PM, Greg Clayton wrote: > > One thing that we have talked about is to move the ProcessWindows stuff > into lldb-server (it has a NativeProcess and NativeThread class you would > need to subclass instead of making ProcessWindows and ThreadWindows > classes) instead of making a native plug-in that is only useful on the > current system. Then remote windows debugging would be possible. It would > end up using thee ProcessGDBRemote.cpp process plug-in then. Then the > ProcessWindows plugin directory would not be needed. Any thoughts on this? > > Greg > > > On Nov 18, 2016, at 4:00 PM, Adrian McCarthy via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > If you're not working in LLDB's Windows process plugin, you probably > don't care about this message. > > > > FYI: I'm doing some refactoring (actually unfactoring) in the Windows > process plugin. It'll take a series patches over a few days next week. If > you're planning on working in this area, please let me know so we can > coordinate. > > > > Details: > > > > Last year, I factored the classes like ProcessWindows into pairs of > classes with names like ProcessWindows and ProcessWindowsLive so that I > could introduce classes like ProcessWindowsMiniDump that shared common > code. Now that the Windows-specific minidump plugin has been superseded by > the cross-platform minidump plugin, this factoring is no longer necessary. > Since the factoring creates extra layers that make the code harder to > understand and maintain, I'd like to undo the split. > > > > My plan is to do this in three NFC patches: > > > > Patch 1. Roll the functionality from the common classes into the -Live > classes. This will eliminate everything under > Plugins/Process/Windows/Common and leave the functional code in > Process/Plugins/Windows/Live. > > > > Patch 2. Rename the -Live classes to shorter, more tractable names. > > > > Patch 3. Move the code up from the Live subdirectory so that it once > again lives in Plugins/Process/Windows. > > > > Patches 2 and 3 could be done in a single step, but I think the history > will be easier to follow if I keep them separate. > > > > If you have any concerns about this plan, please let me know. > > > > Adrian. > > > > > > ___ > > lldb-dev mailing list > > lldb-dev@lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
