Re: [lldb-dev] Weird stop stack while hitting breakpoint
Ok, so the reason for this behavior seems to be that the process hits two breakpoints simultaneously: - the breakpoint you have set and you are expecting to hit - an internal shared library breakpoint we use to get notified of new shared libraries * thread #1: tid = 33390, 0x7ff7dcd9f970 ld-linux-x86-64.so.2`_dl_debug_state, name = 'a.out', stop reason = shared-library-event * frame #0: 0x7ff7dcd9f970 ld-linux-x86-64.so.2`_dl_debug_state frame #1: 0x7ff7dcda3b05 ld-linux-x86-64.so.2`___lldb_unnamed_symbol90$$ld-linux-x86-64.so.2 + 357 frame #2: 0x7ff7dcd9eff4 ld-linux-x86-64.so.2`___lldb_unnamed_symbol59$$ld-linux-x86-64.so.2 + 116 frame #3: 0x7ff7dcda33bb ld-linux-x86-64.so.2`___lldb_unnamed_symbol88$$ld-linux-x86-64.so.2 + 171 frame #4: 0x7ff7dc5de0f2 libc.so.6`do_dlopen(ptr=0x7ffed953c6f0) + 66 at dl-libc.c:87 frame #5: 0x7ff7dcd9eff4 ld-linux-x86-64.so.2`___lldb_unnamed_symbol59$$ld-linux-x86-64.so.2 + 116 frame #6: 0x7ff7dc5de1b2 libc.so.6`__GI___libc_dlopen_mode + 47 at dl-libc.c:46 frame #7: 0x7ff7dc5de183 libc.so.6`__GI___libc_dlopen_mode(name=, mode=) + 35 at dl-libc.c:163 frame #8: 0x7ff7dc87da43 libpthread.so.0`pthread_cancel_init + 35 at unwind-forcedunwind.c:52 frame #9: 0x7ff7dc87dc0c libpthread.so.0`_Unwind_ForcedUnwind(exc=0x7ff7dcf8ddf0, stop=(libpthread.so.0`unwind_stop at unwind.c:44), stop_argument=0x7ffed953c7f0) + 60 at unwind-forcedunwind.c:129 frame #10: 0x7ff7dc87bd40 libpthread.so.0`__GI___pthread_unwind(buf=) + 64 at unwind.c:129 frame #11: 0x7ff7dc876535 libpthread.so.0`__pthread_exit + 37 at pthreadP.h:280 frame #12: 0x7ff7dc87651d libpthread.so.0`__pthread_exit(value=) + 13 at pthread_exit.c:29 frame #13: 0x00400b00 a.out`main + 186 frame #14: 0x7ff7dc4c9ec5 libc.so.6`__libc_start_main(main=(a.out`main), argc=1, argv=0x7ffed953c8a8, init=, fini=, rtld_fini=, stack_end=0x7ffed953c898) + 245 at libc-start.c:287 frame #15: 0x00400939 a.out`_start + 41 thread #2: tid = 35166, 0x004009fd a.out`PrintHello(void*), name = 'a.out', stop reason = breakpoint 1.1 frame #0: 0x004009fd a.out`PrintHello(void*) frame #1: 0x7ff7dc875182 libpthread.so.0`start_thread(arg=0x7ff7dbf8b700) + 194 at pthread_create.c:312 frame #2: 0x7ff7dc5a247d libc.so.6`__clone + 109 at clone.S:111 These internal breakpoints are normally ignored, but I can certainly imagine that if you hit them concurrently with a regular breakpoint, the thread-selecting machinery will get confused. I don't have time to look into this more right now, but I'll get to it eventually if someone doesn't beat me to it... PS: Your inferior is quite strange. I am not sure you are allowed to exit the main thread via pthread_exit(), especially when you still have non-detached threads running... pl On 21 March 2016 at 05:03, Jeffrey Tan wrote: > Thanks guys. I tried our IDE against a sample multithreading program on Mac, > it correctly switches selected thread to the worker thread that triggers > breakpoint, while on Linux(CentOS release 6.7) it failed to do that. Repro > code: > > =Output= > Launch result: success > Listening Thread ID: 139749072582400 > running_signal wait > stopped_signal wait > Target event: ModulesLoaded > Target event: ModulesLoaded > Target event: ModulesLoaded > Target event: ModulesLoaded > Target event: ModulesLoaded > Target event: ModulesLoaded > Target event: ModulesLoaded > Target event: ModulesLoaded > Non stopping event: 'lldb::SBEvent *' at 0x7f19e0975990> > > Process event: StateChanged, Running > Stop reason: 1 > Process event: Stdout, Running > Stop reason: 1 > Stdout: > main() : creating thread, 0 > Process event: StateChanged, Stopped > after wait_for_process_run_then_stop > frame #0: 0x7fcb7259ceb0 ld-linux-x86-64.so.2`__GI__dl_debug_state > frame #1: 0x7fcb725a0c53 ld-linux-x86-64.so.2`dl_open_worker + 499 > frame #2: 0x7fcb7259c286 ld-linux-x86-64.so.2`_dl_catch_error + 102 > frame #3: 0x7fcb725a063a ld-linux-x86-64.so.2`_dl_open + 186 > frame #4: 0x7fcb71963c60 libc.so.6`do_dlopen + 64 > frame #5: 0x7fcb7259c286 ld-linux-x86-64.so.2`_dl_catch_error + 102 > frame #6: 0x7fcb71963db7 libc.so.6`__GI___libc_dlopen_mode + 71 > frame #7: 0x7fcb71be0eec libpthread.so.0`pthread_cancel_init + 76 > frame #8: 0x7fcb71be104c libpthread.so.0`_Unwind_ForcedUnwind + 60 > frame #9: 0x7fcb71bdef60 libpthread.so.0`__GI___pthread_unwind + 64 > frame #10: 0x7fcb71bd9175 libpthread.so.0`__pthread_exit + 37 > frame #11: 0x00400ac0 threads`main + 195 at threads.cpp:31 > frame #12: 0x7fcb7185bd5d libc.so.6`__libc_start_main + 253 > frame #13: 0x004008f9 threads > Exiting listener thread > > =Inferior= > #include > #include > #include > > using namespace st
[lldb-dev] [RFC] Contributing platform support for Linux on SystemZ
Hello, I've been working on adding support for Linux on SystemZ as a target (and host) platform for LLDB, and now have a patch set ready that I'd like to submit for upstream inclusion. For reference, I've attached the patch set as a quilt stack. (See attached file: patches-lldb-s390x.tar.bz2) I'd be happy to split it out into one email per patch or use Phabricator, whatever you prefer. I'd also appreciate suggestions for potential reviewers I could list on Phabricator revisions for each of the affected areas. This is my first contribution to LLDB, and I'm not really familiar with the community yet. There's a number of separate changes implemented by the patch set. First of all, I ran into three problems that seem to be platform-independent, but are related to version and implementation details of the linker and libc library in use on the system, which is why they may not show up everywhere (but they certainly caused many test case failures on my system). These are: - LLDB was unable to find the .plt section and therefore did not identify PLT call stubs (see diff-pltsection) - LLDB would sometimes not find DWARF CFI entries if the PC points one beyond the end of a function (see diff-tailcall) - LLDB would fail expression evaluation if clang asks for an identifier that exists both as type name and variable name (see diff-typelookup) Next, I had to add one new member routine to the ABI class. This was necessary since on SystemZ, the CFA does not equal the incoming stack pointer value (like LLDB unwind code assumes), but instead is offset by a constant, i.e. CFA = incoming SP + 160. The new ABI member CFAOffset allows a platform to provide this offset of the CFA relative to the SP to common unwind code (see diff-cfaoffset). The patch diff-s390x then adds all the new back-end code to support Linux on SystemZ. Its only strict pre-requisite is diff-cfaoffset. Changes includes in this patch are: - A new ArchSpec value of eCore_s390x_generic - A new directory Plugins/ABI/SysV-s390x providing an ABI implementation - Register context support - Native Linux support including watchpoint support - ELF core file support - Misc. support throughout the code base (e.g. breakpoint opcodes) - Test case updates to support the platform This should provide complete support for debugging the base SystemZ platform. Not yet supported are optional features like transaction support (zEC12) or SIMD vector support (z13). Note that there is no instruction emulation, since our ABI requires that all code provides correct DWARF CFI in .eh_frame to support unwinding. However, after that there are still many failing test cases due to various bugs in common code. The patch diff-signedchar fixes a number of problems caused by LLDB assuming a plain "char" type is signed; this is actually platform-specific, and on SystemZ, char is in fact unsigned. The remaining patches fix many problems throughout the code base affecting big-endian platforms (like SystemZ). The biggest problem was that pretty much every access to APInt.getRawData (mostly via the Scalar class, but in a couple of other places as well) was incorrect on big-endian systems. This is fixed in diff-endian-scalar, which requires diff-getbytes-const as pre-requisite, a patch that changes RegisterValue so as to allow Scalar.getBytes to be made const. Other endian related issues were: - Bit field numbering didn't work correctly (see diff-endian-bitfield) - Some smaller miscellaneous issues (see diff-endian-misc) - ARM instruction emulation tests wouldn't work on big-endian host systems (see diff-endian-armemu) - Misc. test cases made byte order assumptions (see diff-endian-tests) With the full patch stack applied on a current LLDB code base (rev. 265656), I'm getting a clean test suite run on the platform: === Test Result Summary === Test Methods: 1684 Reruns:0 Success:1046 Expected Failure:114 Failure: 0 Error: 0 Exceptional Exit: 0 Unexpected Success: 21 Skip:503 Timeout: 0 Expected Timeout: 0 Looking forward to working with you on getting SystemZ support upstream! I'd also be happy to take on ongoing maintenance (setting up a build bot, fixing issues as they come up, etc ...). Bye, Ulrich patches-lldb-s390x.tar.bz2 Description: Binary data ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 27227] TestImport fails on Python 3
https://llvm.org/bugs/show_bug.cgi?id=27227 Adrian McCarthy changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|lldb-dev@lists.llvm.org |amcca...@google.com --- Comment #1 from Adrian McCarthy --- Root cause was failure to escape the backslashes in a path on Windows. http://reviews.llvm.org/rL265738 -- 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] Weird stop stack while hitting breakpoint
Thank you Pavel! That's interesting. Not that urgent, I have a workaround for this issue. For the inferior, I just copied some random multithreading code from internet to demonstrate this issue, definitely a good way exit main thread :-). Btw: I was surprised on Mac/Linux the whole process is still alive after main thread exits, I thought main thread C runtime will kill whole process, maybe it is pthread_exit() that prevent C runtime from killing process.(Sorry, newbie to Mac/Linux) Jeffrey On Fri, Apr 8, 2016 at 4:32 AM, Pavel Labath wrote: > Ok, so the reason for this behavior seems to be that the process hits > two breakpoints simultaneously: > - the breakpoint you have set and you are expecting to hit > - an internal shared library breakpoint we use to get notified of new > shared libraries > > * thread #1: tid = 33390, 0x7ff7dcd9f970 > ld-linux-x86-64.so.2`_dl_debug_state, name = 'a.out', stop reason = > shared-library-event > * frame #0: 0x7ff7dcd9f970 ld-linux-x86-64.so.2`_dl_debug_state > frame #1: 0x7ff7dcda3b05 > ld-linux-x86-64.so.2`___lldb_unnamed_symbol90$$ld-linux-x86-64.so.2 + > 357 > frame #2: 0x7ff7dcd9eff4 > ld-linux-x86-64.so.2`___lldb_unnamed_symbol59$$ld-linux-x86-64.so.2 + > 116 > frame #3: 0x7ff7dcda33bb > ld-linux-x86-64.so.2`___lldb_unnamed_symbol88$$ld-linux-x86-64.so.2 + > 171 > frame #4: 0x7ff7dc5de0f2 > libc.so.6`do_dlopen(ptr=0x7ffed953c6f0) + 66 at dl-libc.c:87 > frame #5: 0x7ff7dcd9eff4 > ld-linux-x86-64.so.2`___lldb_unnamed_symbol59$$ld-linux-x86-64.so.2 + > 116 > frame #6: 0x7ff7dc5de1b2 libc.so.6`__GI___libc_dlopen_mode + > 47 at dl-libc.c:46 > frame #7: 0x7ff7dc5de183 > libc.so.6`__GI___libc_dlopen_mode(name=, > mode=) + 35 at dl-libc.c:163 > frame #8: 0x7ff7dc87da43 libpthread.so.0`pthread_cancel_init + > 35 at unwind-forcedunwind.c:52 > frame #9: 0x7ff7dc87dc0c > libpthread.so.0`_Unwind_ForcedUnwind(exc=0x7ff7dcf8ddf0, > stop=(libpthread.so.0`unwind_stop at unwind.c:44), > stop_argument=0x7ffed953c7f0) + 60 at unwind-forcedunwind.c:129 > frame #10: 0x7ff7dc87bd40 > libpthread.so.0`__GI___pthread_unwind(buf=) + 64 at > unwind.c:129 > frame #11: 0x7ff7dc876535 libpthread.so.0`__pthread_exit + 37 > at pthreadP.h:280 > frame #12: 0x7ff7dc87651d > libpthread.so.0`__pthread_exit(value=) + 13 at > pthread_exit.c:29 > frame #13: 0x00400b00 a.out`main + 186 > frame #14: 0x7ff7dc4c9ec5 > libc.so.6`__libc_start_main(main=(a.out`main), argc=1, > argv=0x7ffed953c8a8, init=, fini=, > rtld_fini=, stack_end=0x7ffed953c898) + 245 at > libc-start.c:287 > frame #15: 0x00400939 a.out`_start + 41 > > thread #2: tid = 35166, 0x004009fd a.out`PrintHello(void*), > name = 'a.out', stop reason = breakpoint 1.1 > frame #0: 0x004009fd a.out`PrintHello(void*) > frame #1: 0x7ff7dc875182 > libpthread.so.0`start_thread(arg=0x7ff7dbf8b700) + 194 at > pthread_create.c:312 > frame #2: 0x7ff7dc5a247d libc.so.6`__clone + 109 at clone.S:111 > > > These internal breakpoints are normally ignored, but I can certainly > imagine that if you hit them concurrently with a regular breakpoint, > the thread-selecting machinery will get confused. I don't have time to > look into this more right now, but I'll get to it eventually if > someone doesn't beat me to it... > > > PS: Your inferior is quite strange. I am not sure you are allowed to > exit the main thread via pthread_exit(), especially when you still > have non-detached threads running... > > pl > > > On 21 March 2016 at 05:03, Jeffrey Tan wrote: > > Thanks guys. I tried our IDE against a sample multithreading program on > Mac, > > it correctly switches selected thread to the worker thread that triggers > > breakpoint, while on Linux(CentOS release 6.7) it failed to do that. > Repro > > code: > > > > =Output= > > Launch result: success > > Listening Thread ID: 139749072582400 > > running_signal wait > > stopped_signal wait > > Target event: ModulesLoaded > > Target event: ModulesLoaded > > Target event: ModulesLoaded > > Target event: ModulesLoaded > > Target event: ModulesLoaded > > Target event: ModulesLoaded > > Target event: ModulesLoaded > > Target event: ModulesLoaded > > Non stopping event: > 'lldb::SBEvent *' at 0x7f19e0975990> > > > Process event: StateChanged, Running > > Stop reason: 1 > > Process event: Stdout, Running > > Stop reason: 1 > > Stdout: > > main() : creating thread, 0 > > Process event: StateChanged, Stopped > > after wait_for_process_run_then_stop > > frame #0: 0x7fcb7259ceb0 ld-linux-x86-64.so.2`__GI__dl_debug_state > > frame #1: 0x7fcb725a0c53 ld-linux-x86-64.so.2`dl_open_worker + 499 > > frame #2: 0x7fcb7259c286 ld-linux-x86-64.so.2`_dl_catch_error + 102 > > frame #3: 0x7fcb725a063a ld-linux-x86-64.so.2`_dl_open + 186 > > frame #4: 0x7fcb71963c60 libc.so.6`do_d
