Re: [lldb-dev] lldb test suite on macOS 10.13 (High Sierra)

2017-12-19 Thread Pavel Labath via lldb-dev
On 18 December 2017 at 23:51, Adrian Prantl wrote: > I also just hit this and apparently this is an intentional behavior of xcrun. > > Note that this only affects systems that have the so-called command line > tools installed (this is what you get when you install the command

Re: [lldb-dev] lldb test suite on macOS 10.13 (High Sierra)

2017-12-19 Thread Pavel Labath via lldb-dev
On 19 December 2017 at 18:06, Greg Clayton wrote: > > The crash hook is needed since ReportCrash on MacOS knows how to dig up a > crash log line for each shared library that is currently loaded in a process > when it generates a crash report. There are settings that we can

Re: [lldb-dev] Resolving dynamic type based on RTTI fails in case of type names inequality in DWARF and mangled symbols

2017-12-20 Thread Pavel Labath via lldb-dev
On 19 December 2017 at 17:39, Greg Clayton via lldb-dev wrote: > The apple accelerator tables are only enabled for Darwin target, but there > is nothing to say we couldn't enable these for other targets in ELF files. > It would be a quick way to gauge the performance

Re: [lldb-dev] lldb test suite on macOS 10.13 (High Sierra)

2017-11-16 Thread Pavel Labath via lldb-dev
ild >>> anything w/o an Xcode install. There’s a “command line tools” package in >>> the Developer tools that puts some stuff back in /usr but that has had some >>> issues, mostly it overwrites the /usr/bin/clang etc. tools that Xcode uses >>> - which are ju

[lldb-dev] lldb test suite on macOS 10.13 (High Sierra)

2017-11-15 Thread Pavel Labath via lldb-dev
Hello lldb-dev, We've just updated our mac buildbot to 10.13.1 (from 10.10.x), and we're having trouble with the lldb test suite. All of the tests are failing with the following error: /Users/lldb_build/lldbSlave/buildDir/llvm/tools/lldb/packages/Python/lldbsuite/test/crashinfo.c:15:10: fatal

Re: [lldb-dev] lldb test suite on macOS 10.13 (High Sierra)

2017-11-15 Thread Pavel Labath via lldb-dev
On a somewhat tangential note: Is anyone actually using this crashinfo hook? It looks like this could be useful in the old dotest days, when we were running all of the tests in a single python process, but now with the parallel test runner spawning a new process for each test file and with piping

Re: [lldb-dev] purpose of ProcessGDBRemote::m_flags

2017-11-03 Thread Pavel Labath via lldb-dev
If it's not used, we should just remove it. Once we have a use case for something like that, we can consider whether the Architecture plugin would be the proper place for it. On 3 November 2017 at 14:27, Tatyana Krasnukha via lldb-dev wrote: > Hello, > > > > I have

Re: [lldb-dev] purpose of ProcessGDBRemote::m_flags

2017-11-03 Thread Pavel Labath via lldb-dev
gone in r317377 On 3 November 2017 at 21:42, Tatyana Krasnukha via lldb-dev wrote: > Sorry, I was unclear – I mean existing recently added plugin “Architecture”. > And “dynamic” configuration is not necessary retrieved from gdb-server. > > > > From: Greg Clayton

Re: [lldb-dev] Bot failure with new "in tree compiler" changes (r316728) in llvm.org bot

2017-11-07 Thread Pavel Labath via lldb-dev
You probably just need to nuke the build folder. The reason for that is that before the patch the LLDB_TEST_C_COMPILER variable was used for a different purpose (and usually empty), where as now it's set by default to the in-tree clang. However, cmake will not overwrite the cached value by

Re: [lldb-dev] Allocation memory is failing in PPC64le

2017-12-05 Thread Pavel Labath via lldb-dev
On linux, we allocate memory by setting up the inferior registers to appear as if the inferior called mmap(2) upon resume. This is done in InferiorCallMmap. You should check whether this function sets up the context correctly. Things to look at are: - did it find the mmap address correctly? - are

Re: [lldb-dev] gdb-remote incompatibility with gdbserver?

2017-12-06 Thread Pavel Labath via lldb-dev
On 6 December 2017 at 12:40, Pedro Alves via lldb-dev wrote: > On 12/05/2017 11:17 PM, David Manouchehri wrote: >> Is there a user accessible setting to force on XML target descriptions >> in new-gdbsever? > > In gdbserver? Nope. > > There's a setting in GDB to force it

Re: [lldb-dev] lldb test suite on macOS 10.13 (High Sierra)

2017-12-08 Thread Pavel Labath via lldb-dev
sure how you worked around, as I tried to export > SDKROOT=macosx but that didn't work for me. > Do you have a patch or a series of commands I can run? > > Thanks, > > -- > Davide > > On Thu, Nov 16, 2017 at 4:25 AM, Pavel Labath via lldb-dev > <lldb-dev@lists.llvm

Re: [lldb-dev] What's the best way to use "--all-files" option from python?

2017-10-25 Thread Pavel Labath via lldb-dev
On 25 October 2017 at 09:41, Greg Clayton via lldb-dev wrote: > Are glob characters legal file characters on any systems? All unix systems accept '*' as file names. In fact, the only system I know of, where that is not a legal filename is windows.

Re: [lldb-dev] clang::VersionTuple

2018-05-09 Thread Pavel Labath via lldb-dev
to, we don’t link new LLDBs to old clangs (and even if we did, it wouldn’t be something the that drives community decisions). > Fred > Greg > On Tue, May 8, 2018 at 9:26 AM Greg Clayton via lldb-dev < lldb-dev@lists.llvm.org> wrote: >> No issues from me. >> > On May 8,

Re: [lldb-dev] What should SymbolFile::FindFunctions(..., eFunctionNameTypeFull, ...) do ?

2018-05-08 Thread Pavel Labath via lldb-dev
On Fri, 4 May 2018 at 17:31, Greg Clayton wrote: > > On May 4, 2018, at 4:58 AM, Pavel Labath wrote: > > Is it really OK? If our indexes will never contain the demangled names, > > then the IRExecutionUnit lookups using the demangled names will always > >

Re: [lldb-dev] What should SymbolFile::FindFunctions(..., eFunctionNameTypeFull, ...) do ?

2018-05-09 Thread Pavel Labath via lldb-dev
On Tue, 8 May 2018 at 10:51, Pavel Labath wrote: > On Fri, 4 May 2018 at 17:31, Greg Clayton wrote: > > > On May 4, 2018, at 4:58 AM, Pavel Labath wrote: > > > Is it really OK? If our indexes will never contain the demangled names, > >

Re: [lldb-dev] LLDB tests getting stuck on GDBRemoteCommunicationClientTest.GetMemoryRegionInfo ?

2018-04-27 Thread Pavel Labath via lldb-dev
On Thu, 26 Apr 2018 at 22:58, Leonard Mosescu via lldb-dev < lldb-dev@lists.llvm.org> wrote: > I just did a clean build (debug) on Linux, and I noticed that the LLDB tests seem to consistently get stuck: > -- Testing: 1002 tests, 12

[lldb-dev] clang::VersionTuple

2018-05-08 Thread Pavel Labath via lldb-dev
While moving Args around, I noticed that we have a bunch of functions/classes that pass/store version numbers as a triplet of integers (e.g. Platform::GetOSVersion). I got halfway into creating a wrapper class for that when I noticed clang::VersionTuple, which is pretty much what I wanted out of

Re: [lldb-dev] What should SymbolFile::FindFunctions(..., eFunctionNameTypeFull, ...) do ?

2018-05-04 Thread Pavel Labath via lldb-dev
Thank you for the detailed response. My replies are below. On Thu, 3 May 2018 at 16:53, Greg Clayton <clayb...@gmail.com> wrote: > On May 3, 2018, at 7:38 AM, Pavel Labath via lldb-dev < lldb-dev@lists.llvm.org> wrote: > - for the manual case (SymbolFileDWARF.cpp:2626), the

Re: [lldb-dev] Advice on architectures with multiple address spaces

2018-05-17 Thread Pavel Labath via lldb-dev
The Address class may be suitable for the higher layers of lldb, but I don't think the it can ever be a blanket replacement for lldb::addr_t. It has way too much smartness built-in. We use addr_t in a lot of places that don't/shouldn't care about Targets, ExecutionContexts or Sections. All of

Re: [lldb-dev] LLDB fails to load C++ Plugin (sharedlib) - error: this file does not represent a loadable dylib

2018-06-08 Thread Pavel Labath via lldb-dev
I would expect the issue is that dlopen fails to locate the dependent libraries of your plugin. Can you lookup the actual dlopen call which opens your library and see what is the exact error it fails with? On Fri, 8 Jun 2018 at 10:52, Bewoayia Kebianyor via lldb-dev wrote: > > Hello Everyone, > >

Re: [lldb-dev] clang::VersionTuple

2018-06-18 Thread Pavel Labath via lldb-dev
Thanks. I am going to submit the patch then. On Fri, 15 Jun 2018 at 19:56, Jim Ingham wrote: > > On Jun 15, 2018, at 3:44 AM, Pavel Labath via lldb-dev > > wrote: > > > > Hello again, > > > > Just a quick update on the state of this. > > > > I've

Re: [lldb-dev] Adding DWARF5 accelerator table support to llvm

2018-06-13 Thread Pavel Labath via lldb-dev
Hello again, It's been nearly six months since my first email, so it's a good time to recap what has been done here so far. I am happy to report that stages 1-3 (i.e. producer/consumer in llvm and integration with lldb) of my original plan are now complete with one caveat. The caveat is that the

Re: [lldb-dev] [llvm-dev] Adding DWARF5 accelerator table support to llvm

2018-06-14 Thread Pavel Labath via lldb-dev
On Thu, 14 Jun 2018 at 19:29, Pavel Labath wrote: > > On Thu, 14 Jun 2018 at 19:26, David Blaikie wrote: > > > > > > > > On Thu, Jun 14, 2018 at 11:24 AM Pavel Labath wrote: > >> > >> On Thu, 14 Jun 2018 at 17:58, Greg Clayton wrote: > >> > > >> > > >> > > >> > On Jun 14, 2018, at 9:36 AM,

Re: [lldb-dev] [llvm-dev] Adding DWARF5 accelerator table support to llvm

2018-06-14 Thread Pavel Labath via lldb-dev
On Thu, 14 Jun 2018 at 17:58, Greg Clayton wrote: > > > > On Jun 14, 2018, at 9:36 AM, Adrian Prantl wrote: > > > > On Jun 14, 2018, at 7:01 AM, Pavel Labath via llvm-dev > wrote: > > Thank you all. I am going to try to reply to all comments in a single email. > > Regarding the .apple_objc

Re: [lldb-dev] [llvm-dev] Adding DWARF5 accelerator table support to llvm

2018-06-14 Thread Pavel Labath via lldb-dev
On Thu, 14 Jun 2018 at 19:26, David Blaikie wrote: > > > > On Thu, Jun 14, 2018 at 11:24 AM Pavel Labath wrote: >> >> On Thu, 14 Jun 2018 at 17:58, Greg Clayton wrote: >> > >> > >> > >> > On Jun 14, 2018, at 9:36 AM, Adrian Prantl wrote: >> > >> > >> > >> > On Jun 14, 2018, at 7:01 AM, Pavel

Re: [lldb-dev] clang::VersionTuple

2018-06-15 Thread Pavel Labath via lldb-dev
> repositories that link against older llvm/clang. Doesn't affect me anymore, > but Apple will be affected. > > > > I’m not sure I understand what issues you’re referring to, we don’t link > new LLDBs to old clangs (and even if we did, it wouldn’t be something the > that drives

Re: [lldb-dev] [llvm-dev] Adding DWARF5 accelerator table support to llvm

2018-06-15 Thread Pavel Labath via lldb-dev
I wasn't using type units (those don't work at all right now). I've done a bit of digging, and i found this patch which explicitly disables template member function parsing (though it seems it didn't really work before either). The patch contains a quite long

Re: [lldb-dev] Adding DWARF5 accelerator table support to llvm

2018-06-14 Thread Pavel Labath via lldb-dev
Thank you all. I am going to try to reply to all comments in a single email. Regarding the .apple_objc idea, I am afraid the situation is not as simple as just flipping a switch. (If it was, I don't think I would have embarked on this adventure in the first place -- I would just emit .apple_***

Re: [lldb-dev] [llvm-dev] Adding DWARF5 accelerator table support to llvm

2018-06-15 Thread Pavel Labath via lldb-dev
On Fri, 15 Jun 2018 at 20:14, David Blaikie wrote: > > How do you handle name lookup for nested classes? They have the same problem > (they don't appear in all definitions) - don't appear in all descriptions of > the outer/parent class. (in theory we could ensure there's always at least a >

Re: [lldb-dev] LLDB Process Attach Failed When Waiting

2018-06-05 Thread Pavel Labath via lldb-dev
On Tue, 5 Jun 2018 at 01:18, Ryan Lovelett via lldb-dev wrote: > > So I've found a capability on Linux to be notified about new processes. I > have an example of listening for these new processes running on my machine > now [1] and I can see when my desired user process spawns. Though >

Re: [lldb-dev] LLDB Process Attach Failed When Waiting

2018-06-06 Thread Pavel Labath via lldb-dev
There is some documentation on the packets in docs/lldb-gdb-remote.txt in the lldb repo, though for this particular packet it does not say much about the encoding (patches welcome). That said, it looks like the format is just that we send the process name hex-encoded. For that you can simply use

Re: [lldb-dev] LLDB Process Attach Failed When Waiting

2018-06-06 Thread Pavel Labath via lldb-dev
There are other options available as well, but for this particular scenario, I'd go with the following: - start debugging the client, set a breakpoint just before it sends the vAttach packet - when the client reaches this breakpoint, attach a debugger to the server (it will already be running at

Re: [lldb-dev] MacOS minidump debugging

2018-06-06 Thread Pavel Labath via lldb-dev
We don't have support for reading mac minidumps presently. That said, it probably wouldn't be too hard to add one, as we already have windows and linux minidumps working (to some degree, at least). It would probably require adding parsing support for some OS-specific structures (I recall some

Re: [lldb-dev] LLDB Process Attach Failed When Waiting

2018-06-07 Thread Pavel Labath via lldb-dev
sleep_for is definitely better than usleep because of portability (and we use it elsewhere already). Could you attach the patch to phabricator instead ? It's easier to make comments and iterate there. When you upload the patch be sure to include full

Re: [lldb-dev] Linux: Failing lldb unit tests and TestLinuxCore.py

2018-06-26 Thread Pavel Labath via lldb-dev
Hello Gabor, The error message (Option 'help-list' registered more than once) leads me to believe that this is caused by an uncommon (for lldb, at least) build configuration. Can you share your cmake configuration? I suspect TestLinuxCore is also failing due to unexpected build configuration,

Re: [lldb-dev] Linux: Failing lldb unit tests and TestLinuxCore.py

2018-06-26 Thread Pavel Labath via lldb-dev
The BUILD_SHARED_LIBS part is likely to be the issue. LLDB libraries have cyclic dependencies, which don't play well with shared libraries. I think somebody "fixed" it some time ago (i.e., just made the flag be ignored for lldb), but I'm not sure if he also checked the unit tests. I'll see if I

Re: [lldb-dev] RFC: libtrace

2018-06-27 Thread Pavel Labath via lldb-dev
On Wed, 27 Jun 2018 at 14:11, Zachary Turner wrote: > > suppose process A (single threaded) is tracing process B (2 threads). If > trace events happen on both threads of B, then the second thread can’t > continue until both threads’ trace events have been fully handled, > synchronously. If

Re: [lldb-dev] RFC: libtrace

2018-06-27 Thread Pavel Labath via lldb-dev
On Wed, 27 Jun 2018 at 01:14, Zachary Turner via lldb-dev wrote: > > Yes that’s what I’ve been thinking about as well. > > One thing I’ve been giving a lot of thought to is whether to serialize the > handling of trace events. I want to balance the “this is a library and you > should be able to

Re: [lldb-dev] LLDB tests getting stuck on GDBRemoteCommunicationClientTest.GetMemoryRegionInfo ?

2018-05-02 Thread Pavel Labath via lldb-dev
Right, I see what's going on now. Yes, you're right, the commit you mention has added extra packets which are not handled in the mock. The reason this is hanging for you is because you are using a debug build, which has a much larger packet timeout (1000s i think). In the release build this

Re: [lldb-dev] LLDB tests getting stuck on GDBRemoteCommunicationClientTest.GetMemoryRegionInfo ?

2018-05-02 Thread Pavel Labath via lldb-dev
Ok, r331374 ought to fix that. The situation was a bit more complicated then I thought, because the function was behaving differently if one builds lldb with xml support, so i've had to update the test to work correctly in both situations. On Wed, 2 May 2018 at 16:34, Pavel Labath

Re: [lldb-dev] Dlopen extremely slow while LLDB is attached

2018-05-01 Thread Pavel Labath via lldb-dev
On Mon, 30 Apr 2018 at 20:13, Scott Funkenhauser wrote: > I messed up my test setup and incorrectly attributed the additional time. Parsing the DWARF sections does add additional time, but only increases by a small percentage. > By pure chance I noticed that the

Re: [lldb-dev] Proposal: Using LLD in tests

2018-05-01 Thread Pavel Labath via lldb-dev
inux Foundation Collaborative Project > > -Original Message- > > From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Pavel > > Labath via lldb-dev > > Sent: Thursday, April 19, 2018 12:45 PM > > To: Leonard Mosescu <mose...@google.com> > >

[lldb-dev] What should SymbolFile::FindFunctions(..., eFunctionNameTypeFull, ...) do ?

2018-05-03 Thread Pavel Labath via lldb-dev
Hello all, /This may or may not be related to the "Issue with expression parser finding the correct types" thread from last week./ As you probably know, I am working on adding DWARF v5 accelerator tables to lldb. To make that happen, I've been trying to understand how the two existing indexing

Re: [lldb-dev] check-lldb will start using in-tree clang by default

2017-10-27 Thread Pavel Labath via lldb-dev
ype found >> FAILED: cd /home/davide/work/build-lldb/tools/lldb/test && >> /usr/bin/python2.7 >> /home/davide/work/llvm-lldb/tools/lldb/test/dotest.py -q --arch=x86_64 >> --executable /home/davide/work/build-lldb/bin/lldb -s >> /home/davide/work/build-lldb/lldb

Re: [lldb-dev] check-lldb will start using in-tree clang by default

2017-10-27 Thread Pavel Labath via lldb-dev
Error: coercing to Unicode: need string or buffer, NoneType found >>>> FAILED: cd /home/davide/work/build-lldb/tools/lldb/test && >>>> /usr/bin/python2.7 >>>> /home/davide/work/llvm-lldb/tools/lldb/test/dotest.py -q --arch=x86_64 >>>> --exe

Re: [lldb-dev] check-lldb will start using in-tree clang by default

2017-10-27 Thread Pavel Labath via lldb-dev
On 27 October 2017 at 13:28, Zachary Turner wrote: > Maybe make it a dependency of the `check-lldb` target instead of the `lldb` > target? > +1 ___ lldb-dev mailing list lldb-dev@lists.llvm.org

Re: [lldb-dev] check-lldb will start using in-tree clang by default

2017-10-27 Thread Pavel Labath via lldb-dev
Ship it. On 27 October 2017 at 13:56, Davide Italiano wrote: > Take 2 (it can't be in the top-level CMakeList because the check-lldb > target is declared elsewhere). > > $ git diff HEAD > diff --git a/test/CMakeLists.txt b/test/CMakeLists.txt > index d5d71d1..958f9f3

Re: [lldb-dev] [llvm-dev] RFC: Adding a JSON library to LLVM Support

2017-10-27 Thread Pavel Labath via lldb-dev
On 27 October 2017 at 13:23, Sam McCall wrote: > On Fri, Oct 27, 2017 at 10:06 PM, Pavel Labath wrote: >> >> LLDB has a JSON parser/serializer that we'd like to get rid of. > > Ah, sorry for missing that! > What makes you want to get rid of it?

Re: [lldb-dev] lldb test suite on macOS 10.13 (High Sierra)

2018-01-09 Thread Pavel Labath via lldb-dev
On 2 January 2018 at 19:20, Jim Ingham wrote: > This is actually using the same mechanism that Greg was describing, but > through a separate route. > > With the crashinfo mechanism in place, if a test crashes the crash log will > show whatever test was being run at the time

Re: [lldb-dev] Loading object file to target flash memory using vFlashWrite

2018-01-11 Thread Pavel Labath via lldb-dev
On 10 January 2018 at 22:17, Owen Shaw via lldb-dev wrote: > Thanks! > > ObjectFileELF::SetLoadAddress(...) is where I already have a change > that got things working, just wasn't sure if I'd be stepping on > anything else that relied on the values set there. > > Looks

[lldb-dev] Adding DWARF5 accelerator table support to llvm

2018-01-17 Thread Pavel Labath via lldb-dev
Hello all, In it was brought up that there are at least two parties interested in having DWARF5 accelerator tables implemented, so I'm writing this email to see if there's anyone else interested in this topic, and to try to synchronize our efforts. Our

Re: [lldb-dev] [llvm-dev] Adding DWARF5 accelerator table support to llvm

2018-01-18 Thread Pavel Labath via lldb-dev
Thank you for all the responses. Unfortunately I wasn't able to make any progress on creating the patches today. I'll be sure to add everyone who expressed interest here to the phabricator diff once I have them ready. Jonas, do you have any dsymutil patches I can look at? I am interested in

Re: [lldb-dev] Questions about the LLDB testsuite and improving its reliability

2018-01-18 Thread Pavel Labath via lldb-dev
On 18 January 2018 at 17:52, Adrian Prantl wrote: > > >> On Jan 18, 2018, at 5:07 AM, Pavel Labath wrote: >> >> Looks like I missed a party. :) >> >> I'll try to give my thoughts on some of the things that were said here: >> >>> make -C >> I don't think make

Re: [lldb-dev] Questions about the LLDB testsuite and improving its reliability

2018-01-18 Thread Pavel Labath via lldb-dev
Looks like I missed a party. :) I'll try to give my thoughts on some of the things that were said here: > make -C I don't think make -C does what you think it does. "make -C foo" is basically equivalent to "cd foo && make", which is what we are doing now already. Of course, you can make this

Re: [lldb-dev] Anybody using the Go/Java debugger plugins?

2018-01-22 Thread Pavel Labath via lldb-dev
The Go support for added by Ryan as a 20% project. Now that he's no longer working for Google, it's pretty much abandoned. The Java support was added by us (android folks) to support java debugging (to a certain extent). However, we never really finished the project, so we're not using that code

Re: [lldb-dev] Huge mangled names are causing long delays when loading symbol table symbols

2018-01-25 Thread Pavel Labath via lldb-dev
The mangled name length threshold would be the easiest to implement. However, I fear we may not be able to find a good cutoff length, because it's not the length of it that matters, but the number (and recursiveness) of back-references. For example, I was able to find a mangled name of 757

Re: [lldb-dev] [llvm-dev] Adding DWARF5 accelerator table support to llvm

2018-01-30 Thread Pavel Labath via lldb-dev
Hello all, I am looking for feedback regarding implementation of the case folding algorithm for .debug_names hashes. Unlike the apple tables, the .debug_names hashes are computed from case-folded names (to enable case-insensitive lookups for languages where that makes sense). The dwarf5 document

Re: [lldb-dev] [llvm-dev] Adding DWARF5 accelerator table support to llvm

2018-01-30 Thread Pavel Labath via lldb-dev
On 30 January 2018 at 15:41, Adrian Prantl wrote: > > >> On Jan 30, 2018, at 7:35 AM, Pavel Labath wrote: >> >> Hello all, >> >> I am looking for feedback regarding implementation of the case folding >> algorithm for .debug_names hashes. >> >> Unlike the

Re: [lldb-dev] Anybody using the Go/Java debugger plugins?

2018-02-01 Thread Pavel Labath via lldb-dev
On 30 January 2018 at 23:21, Davide Italiano wrote: > I agree. Just to check: Does that apply to Tamas's paragraph below, as in that's the guidelines we should be giving to new language plugin implementors? If that's the case, then I agree as well, although I think we

Re: [lldb-dev] Rust language support question

2018-01-29 Thread Pavel Labath via lldb-dev
To these very insightful emails from Greg and Jim, I'd just like to add one request. Please consider the testing strategy of the code you write early on. One of the problems that we have with these language plugins (and why we now have a separate thread considering removal of some of them) is that

[lldb-dev] Querying build configuration of (lib)lldb from tests.

2018-02-05 Thread Pavel Labath via lldb-dev
Hello all, In we have a feature that only works when lldb was built with xml support. To test this, we need the test to know whether we were build with xml support. The typical llvm solution would be to generate some dotest equivalent of lit.site.cfg at build

Re: [lldb-dev] Rust language support question

2018-01-30 Thread Pavel Labath via lldb-dev
On 29 January 2018 at 18:39, Tom Tromey wrote: >> "Pavel" == Pavel Labath writes: > > Pavel> To these very insightful emails from Greg and Jim, I'd just like to > Pavel> add one request. Please consider the testing strategy of the code you > Pavel>

Re: [lldb-dev] Anybody using the Go/Java debugger plugins?

2018-01-30 Thread Pavel Labath via lldb-dev
it > was pretty thin. I would be okay with pulling that out unless somebody is > actually getting good use out of it. > > Jim > >> On Jan 22, 2018, at 10:17 AM, Pavel Labath via lldb-dev >> <lldb-dev@lists.llvm.org> wrote: >> >> The Go support for

Re: [lldb-dev] [RFC] Testsuite in lldb & possible future directions

2018-02-06 Thread Pavel Labath via lldb-dev
On 6 February 2018 at 15:41, Davide Italiano wrote: > On Tue, Feb 6, 2018 at 7:09 AM, Pavel Labath wrote: >> On 6 February 2018 at 04:11, Davide Italiano via lldb-dev >> >> So, I guess my question is: are you guys looking into making sure that >> others

Re: [lldb-dev] [RFC] Testsuite in lldb & possible future directions

2018-02-06 Thread Pavel Labath via lldb-dev
On 6 February 2018 at 04:11, Davide Italiano via lldb-dev wrote: > Hi, > in the last couple of months a lot of people put a lot of attentions > and energy into lldb and we're starting to see the first results. I > decided to sit down and write this e-mail to state where

Re: [lldb-dev] hashing pointers to strings

2018-02-12 Thread Pavel Labath via lldb-dev
[ Clang's emission of pubnames/pubtypes is controlled by the "debugger tuning" parameter. With -glldb they don't get emitted, with -ggdb, they do. (-glldb is default on mac, -ggdb elsewhere). In dwarf5 these sections have been dropped in favour of the new .debug_names section. ] On 10 February

Re: [lldb-dev] [RFC] Testsuite in lldb & possible future directions

2018-02-07 Thread Pavel Labath via lldb-dev
est framework. So, I'm not sure where you were heading with that question.. On 6 February 2018 at 18:53, Zachary Turner <ztur...@google.com> wrote: > > > On Tue, Feb 6, 2018 at 8:19 AM Pavel Labath via lldb-dev > <lldb-dev@lists.llvm.org> wrote: >> >> On 6 Febru

Re: [lldb-dev] [RFC] Testsuite in lldb & possible future directions

2018-02-07 Thread Pavel Labath via lldb-dev
On 6 February 2018 at 15:51, Davide Italiano wrote: > > FWIW, I strongly believe we should all agree on a configuration to run > tests and standardize on that. > It's unfortunate that we have two build systems, but there are plans > to move away from manually generating

Re: [lldb-dev] Querying build configuration of (lib)lldb from tests.

2018-02-15 Thread Pavel Labath via lldb-dev
config options to answer a single question is going to be a problem, and the >> info is constant for the run of lldb, so you can cache the result. >> >> Jim >> >> >>> On Feb 5, 2018, at 4:01 AM, Pavel Labath via lldb-dev >>> <lldb-dev@lists.llvm.or

Re: [lldb-dev] How to test lldb-vscode?

2018-02-15 Thread Pavel Labath via lldb-dev
Mocking the VS side (in python or C++) sounds like the way to go. I don't know much smartness is in this code (as in, something other than "take this json, translate it to an appropriate SB call and serialize the results back"), but if there is some non-trivial logic in there (perhaps the code

Re: [lldb-dev] Pending breakpoints to dlsym()ed functions

2018-02-15 Thread Pavel Labath via lldb-dev
Yes, it looks that way, but I cannot reproduce this on my side (which is not surprising as it involves parsing debug info from your dynamic linker). I'd need the relevant portions of that file (or just the whole file) to see what's going on there. That said, this shouldn't impact you unless you

Re: [lldb-dev] Pending breakpoints to dlsym()ed functions

2018-02-15 Thread Pavel Labath via lldb-dev
+ eugene as the "most recent person who worked on the DYLD plugin" :D Hi Dmitry, I've tried your sample, and I was indeed able to reproduce the problem. What makes your case special is that "sin" and "cos" are indirect functions (STT_GNU_IFUNC), so we have to do some extra work (call the

Re: [lldb-dev] Current state of the unit tests

2018-02-23 Thread Pavel Labath via lldb-dev
On 23 February 2018 at 15:17, Vedant Kumar wrote: > Second, TestClient::SendMessage is generating quite a lot of "INFO" output > which clutters up the terminal. Pavel, would you mind if I removed this > logging? > Yeah, we should probably do that. The idea here was that the

Re: [lldb-dev] Current state of the unit tests

2018-02-23 Thread Pavel Labath via lldb-dev
Yeah, if a lit test fails, the dotest tests will not get run. That is fine, but having a target which only runs dotest tests would probably be nice as well. On 23 February 2018 at 16:15, Vedant Kumar wrote: > check-lldb-lit should just be a dependency of check-lldb, so the

Re: [lldb-dev] problem with TestLoadUnload.py

2018-02-23 Thread Pavel Labath via lldb-dev
A couple of things here: - there should be no performance difference between doing build in setUp and the test function as setUp is called once per test function - my change was to run have the paralelization at a file level (previously it was at folder-level). All test functions in a single file

Re: [lldb-dev] Current state of the unit tests

2018-02-23 Thread Pavel Labath via lldb-dev
On 23 February 2018 at 16:19, Adrian McCarthy wrote: > I'm also seeing windows appear and quickly vanish a several times while > running the lit tests. That's because the tests run inferiors and lldb on windows will always run them in a separate console window. IIRC, there

Re: [lldb-dev] Resolving dynamic type based on RTTI fails in case of type names inequality in DWARF and mangled symbols

2017-12-22 Thread Pavel Labath via lldb-dev
On 21 December 2017 at 16:22, Greg Clayton wrote: > > > The main idea is to touch as few pages as possible when doing searches. We > effectively have this scenario right now with Apple DWARF in .o file > debugging. So much time is spent paging in each accelerator table that we

Re: [lldb-dev] Resolving dynamic type based on RTTI fails in case of type names inequality in DWARF and mangled symbols

2017-12-21 Thread Pavel Labath via lldb-dev
On 21 December 2017 at 12:29, xgsa <x...@yandex.ru> wrote: > 21.12.2017, 13:45, "Pavel Labath via lldb-dev" <lldb-dev@lists.llvm.org>: >> On 20 December 2017 at 18:40, Greg Clayton <clayb...@gmail.com> wrote: >>>> On Dec 20, 2017, a

Re: [lldb-dev] Resolving dynamic type based on RTTI fails in case of type names inequality in DWARF and mangled symbols

2017-12-21 Thread Pavel Labath via lldb-dev
On 21 December 2017 at 10:45, Pavel Labath wrote: > I'm not sure now whether you're suggesting to use the dsymutil > approach just to gauge the potential speedup we can obtain and get > people interested, or as a productized solution. If it's the first one > then I fully agree

Re: [lldb-dev] Resolving dynamic type based on RTTI fails in case of type names inequality in DWARF and mangled symbols

2017-12-21 Thread Pavel Labath via lldb-dev
That's not the case, the nested debugger get's stopped in CommandObjectTargetCreate::DoExecute before it even touches the /bin/ls file. I could have passed anything there (probably /bin/ls wasn't the best choice though), it's just this was the easiest thing I came up with for stopping at a place

Re: [lldb-dev] LLDB does not support the default 8 byte build ID generated by LLD

2018-06-20 Thread Pavel Labath via lldb-dev
Thanks for the heads up Scott. I was not aware that lld generates build-ids with different length. Padding would be one option (we already do that to handle the crc pseudo-build-ids), but perhaps a better one would be to teach the class how to handle arbitrary-sized UUIDs (or up to 20 bytes, at

Re: [lldb-dev] LLDB does not support the default 8 byte build ID generated by LLD

2018-06-21 Thread Pavel Labath via lldb-dev
That sounds like a plan. I have started cleaning up the class a bit (removing manual uuid string formatting in various places and such), and then I'll send a patch which implements that. Leonard, I'm not going to use your patch, as it's a bit un-llvm-y (uses std::ostream and such). However, I

Re: [lldb-dev] Handling callable addresses

2018-06-22 Thread Pavel Labath via lldb-dev
+1 While creating the architecture plugin, I noticed that this code could be moved there, but never got around to doing that. If the code is indeed equivalent, then we can make a utility function or a common base class that both plugins can then reuse. On Thu, 21 Jun 2018 at 23:34, Greg Clayton

Re: [lldb-dev] run tests with ASAN (dotest.py)

2018-08-03 Thread Pavel Labath via lldb-dev
When I looked into this in the past (two years ago), the problem was that the sanitizer runtimes were expected to be linked into the main executable. For the dotest tests, the main executable is "python", so unless you have built an asanified python, you will not have them. You might be able to

Re: [lldb-dev] run tests with ASAN (dotest.py)

2018-08-03 Thread Pavel Labath via lldb-dev
Hi Gábor, That error is kind of correct. As far as c++ standard is concerned, this is an ODR violation, as both lldb and liblldb link in a copy of LLVMSupport.a. However, all LLVM symbols in liblldb have "hidden" visibility (and we make sure we don't pass around llvm objects on the SO boundary),

Re: [lldb-dev] LLDB Demangling

2018-07-26 Thread Pavel Labath via lldb-dev
On Wed, 25 Jul 2018 at 19:15, Stefan Gränitz wrote: > > right now the Symtab class builds a table containing all > > demangled names. This is mostly unnecessary, and > What exact table are you referring to here? The m_name_to_index map does > store both, demangled and mangled strings. Not sure to

Re: [lldb-dev] Phabricator repository

2018-08-01 Thread Pavel Labath via lldb-dev
Sounds like a good idea, though I'm not sure what specifically needs to be done to make that happen. Eric might know more... On Wed, 1 Aug 2018 at 03:17, Raphael Isemann via lldb-dev wrote: > > Could we get LLDB into this repository list here? > https://reviews.llvm.org/diffusion/ > > Beside that

Re: [lldb-dev] Handling of the ELF files missing build-ids?

2018-08-05 Thread Pavel Labath via lldb-dev
Hello Leonard, while I'm in principle supportive of this idea, I think it's not going to be as easy as you might imagine. There are currently at least two mechanisms which rely on this crc UUID. 1. .gnu_debuglink separate file pointer

Re: [lldb-dev] Firewall complaint about hosttests.exe

2018-08-02 Thread Pavel Labath via lldb-dev
Yes, we have a couple of tests there, which verify that our socket communication works. It seems there is one test which specifically opens a non-localhost socket (TCPListen0GetPort (*)), so I would bet it's that's the one the firewall is having problems with. Or, if you have a particularly

Re: [lldb-dev] buildbot deployment: gsutil: Anonymous caller does not have storage.objects.create access to lldb_test_traces

2018-08-02 Thread Pavel Labath via lldb-dev
On Thu, 2 Aug 2018 at 13:39, Jan Kratochvil wrote: > > On Thu, 02 Aug 2018 13:47:25 +0200, Pavel Labath wrote: > > However, I strongly suspect that you do not want this, > > Right. > > > > *However*, for setting up a new bot, I'd recommend not using this > > particular slave factory

Re: [lldb-dev] buildbot deployment: gsutil: Anonymous caller does not have storage.objects.create access to lldb_test_traces

2018-08-02 Thread Pavel Labath via lldb-dev
This step is very specific to our (android studio) buildbot setup, and it uploads the test results to a google cloud account only accessible to our team. If you wanted to do something like that, you'd have to create your own account and set it up similarly. However, I strongly suspect that you do

Re: [lldb-dev] Handling of the ELF files missing build-ids?

2018-08-07 Thread Pavel Labath via lldb-dev
Sounds like a plan. On Tue, 7 Aug 2018 at 01:30, Leonard Mosescu wrote: >> >> I am fine with all the above except some reservations about case C. No need >> to calculate something if it isn't useful. For case C it should be fine to >> never match as if a file has a UUID to begin with it

Re: [lldb-dev] Remove "Either" or not?

2018-08-07 Thread Pavel Labath via lldb-dev
I'd vote for removal. This kind of functionality would be better off in llvm's ADT anyway. On Tue, 7 Aug 2018 at 09:18, Tatyana Krasnukha via lldb-dev wrote: > > Hello, > > > > lldb\include\lldb\Utility\Either.h seems dead, at least I couldn’t find any > usages. > > I could enhance it with Bind

[lldb-dev] Pavel's status

2018-08-06 Thread Pavel Labath via lldb-dev
Hello all, as some of you may know, this week is my last week at Google. However, I am not planning to disappear from the LLDB/LLVM communities as a result. You should still see me around, only with a new address (pavel AT labath DOT sk). I plan to continue looking out for the linux side of lldb

Re: [lldb-dev] LLDB tests duplicated between lldb-suite and lit

2018-07-18 Thread Pavel Labath via lldb-dev
+1 for removing. I've been wanting to do that for a while now... >> >> Looking at the other duplicated tests, we have the potential for similar >> issues. They also all use CHECK rather then CHECK-DAG, so we should at least >> update them to use CHECK-DAG. Could you elaborate on this? I don't

Re: [lldb-dev] Linux: Failing lldb unit tests and TestLinuxCore.py

2018-07-16 Thread Pavel Labath via lldb-dev
Hi Gábor, sorry for the late reply, I have been OOO. Thanks for the detailed report. I think the fact that we load the system lldb from the unit tests should be considered a bug. I am going to try to find some time fix this issue. thanks, pl On Fri, 29 Jun 2018 at 15:35, Gábor Márton wrote: > >

Re: [lldb-dev] Linux: lldb tests are failed

2018-07-16 Thread Pavel Labath via lldb-dev
Hello Konstantin, that sounds like a good idea. We've had reports of this in the past, but so far noone dug into it to find out what's going on (thank you for that). Can you create a review for this (https://reviews.llvm.org/differential/)? pl On Mon, 9 Jul 2018 at 14:17, k.baladurin via

Re: [lldb-dev] MI Handle events.

2018-07-16 Thread Pavel Labath via lldb-dev
The eStateSuspended state is used for threads (you can set it via SBThread::Suspend/Resume). It controls whether a "continue" operation on the process will run the thread or not. I am not sure if you can ever see that state on the process itself. On Sat, 14 Jul 2018 at 15:39, Adrian Prantl via

Re: [lldb-dev] LLDB does not respect platform sysroot when loading core on Linux

2018-07-23 Thread Pavel Labath via lldb-dev
Instead of "image search-paths add" you should be able to do a "settings append target.exec-search-paths /your/sysroot". That one should not require a running target or anything like that. However, I agree that it would be nice for the platform sysroot to work out of the box. Particularly, as we

<    1   2   3   4   5   >