[lldb-dev] [Bug 31571] lldb 3.8, 3.9 and 4.0 hang on Debian because of the classic "registered more than once" with lldb-server

https://llvm.org/bugs/show_bug.cgi?id=31571 lab...@google.com changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|lldb-dev@lists.l

Re: [lldb-dev] Lldb-server spins forever in ptrace with 100% CPU on Linux Ubuntu 16.04

Nice catch. I think this backtrace should be enough to bring the problem to the attention of the kernel developers. Have you tried contacting them already? I can help you with that if you want. On 6 January 2017 at 23:34, Eugene Birukov wrote: > Hi, > > > It seems the problem is related to trans

Re: [lldb-dev] Lldb-server spins forever in ptrace with 100% CPU on Linux Ubuntu 16.04

Yes, we have contacted RHEL people. It repros there too. Sent from Outlook From: Pavel Labath Sent: Monday, January 9, 2017 2:53 AM To: Eugene Birukov Cc: LLDB Subject: Re: [lldb-dev] Lldb-server spins forever in ptrace with 100% CPU o

[lldb-dev] LLDB failed to locate source when dwarf symbols are inside compile unit on Linux

Hi, O ur company is using Buck(https://buckbuild.com/) to build internal service. Recently the build team made a change in buck to not merge dwarf symbols from each object file into final binary so debugger needs to read source/symbol table from compilation unit itself. This seems to break the lld

Re: [lldb-dev] LLDB failed to locate source when dwarf symbols are inside compile unit on Linux

Comments below. > On Jan 9, 2017, at 1:10 PM, Jeffrey Tan via lldb-dev > wrote: > > Hi, > > O ur company is using Buck(https://buckbuild.com/ ) > to build internal service. Recently the build team made a change in buck to > not merge dwarf symbols from each object fil

Re: [lldb-dev] LLDB failed to locate source when dwarf symbols are inside compile unit on Linux

Hey Greg, I just confirmed this with our build team. I seem to have misunderstood the location of debug symbol. It is actually not inside each individual object file but: The debug info in dev mode sits in the .debug_* sections of the shared libraries (we don't use debug fission). One potential c

Re: [lldb-dev] Prebuilt binary for Windows

Vadim, it looks like your change was committed in r291291, and I've built a new snapshot today which includes it. Can you give it a try and see if everything works? Cheers, Hans On Thu, Jan 5, 2017 at 10:46 AM, Zachary Turner wrote: > I will commit it, in the meantime can you request commit acce

Re: [lldb-dev] LLDB failed to locate source when dwarf symbols are inside compile unit on Linux

In ELF files if there is a section named “.gnu_debuglink” it will contain a path to the external debug file. Dump this section and see what it contains. This section contains a null terminated C string as the path followed by a 4 byte aligned 32 bit integer which is a file CRC. Check to see the

Re: [lldb-dev] Prebuilt binary for Windows

It worked! ...but not before I set PYTHONPATH=C:\Program Files (x86)\LLVM\lib\site-packages\lldb Without that, it couldn't find the _lldb module, so we are not quite out of the woods yet. When are you planning to make the next snapshot build? Thanks! On Mon, Jan 9, 2017 at 3:48 PM, Hans Wennbor

Re: [lldb-dev] Prebuilt binary for Windows

This appears to be a SWIG bug: https://github.com/swig/swig/issues/769 On Mon, Jan 9, 2017 at 9:14 PM, Vadim Chugunov wrote: > It worked! > > ...but not before I set PYTHONPATH=C:\Program Files > (x86)\LLVM\lib\site-packages\lldb > Without that, it couldn't find the _lldb module, so we are not q