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

Hi Pavel, As mentioned by Adrian in the comment you linked, I too am looking at DWARFv5 accelerator tables in LLVM. To give you some background: my motivation is that I want to upstream support for (Apple style) accelerator tables in llvm-dsymutil, which is currently missing because the way they

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

> On Jan 30, 2018, at 3:35 PM, Pavel Labath wrote: > > 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-insensit

Re: [lldb-dev] [llvm-dev] [GSoC] Add support for batch-testing to the LLDB testsuite.

Hi Mark, LLDB has its own mailing list (CC’ed). Feel free to ask questions there about this GSoC project, Jim is an active participant and it’s always good to keep the community informed. Just to be sure I’ve also CC’ed him, so he’ll certainly see your message. Cheers, Jonas > On Mar 19, 201

Re: [lldb-dev] r329889 - Use in-tree dsymutil on Darwin

Hi Ted, I tried to reproduce this issue over the weekend on a Linux machine, but to no success. > On Apr 20, 2018, at 4:46 PM, Ted Woodward via lldb-dev > wrote: > > r329889 says "Use in-tree dsymutil on Darwin", but it's got these change in > test/CMakeLists.txt: > -set(LLDB_TEST_DEPS lldb)

[lldb-dev] London LLVM Social, May 17

Hi everyone, We're excited to invite you to the first LLVM social in London on Thursday, May 17. We'll meet at The Star of Kings (126 York Way, Kings Cross, N1 0AX) at 6:30 pm for an informal evening of LLVM-related discussions over drinks. If you can, help us plan and RSVP here: https://www.

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

Hi Pavel, > On Jun 13, 2018, at 6:56 AM, Pavel Labath wrote: > > 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) >

[lldb-dev] Add LLDB Repository to Phabricator

Hi, It’s currently not possible to set the correct repository for lldb code reviews. Could someone with the right privileges add LLDB to the list of active repositories? (https://reviews.llvm.org/diffusion/) Thanks, Jonas ___ lldb-dev mailing list lld

[lldb-dev] London LLVM Social Thursday July 19

Hi everyone, We’re excited to invite you to the second LLVM social in London on Thursday, July 19. We'll meet at Drake & Morgan (6 Pancras Square, Kings Cross, N1C 4AG) at 6:30 pm for an informal evening of LLVM-related discussions over drinks. If you can, please help us plan and RSVP here: h

Re: [lldb-dev] Issues (resolved) with running lldb test-suite on Ubuntu 18.04 LTS

Hi Puyan, > On Jun 29, 2018, at 7:30 PM, Puyan Lotfi via lldb-dev > wrote: > > Just a heads up, I had run into some issues running make check-lldb. I found > the solution to be setting: > > PYTHON_INCLUDE_DIRS=/usr/include/python2.7 > PYTHON_LIBRARIES=/usr/lib/python2.7/config-x86_64-linux-gn

Re: [lldb-dev] Moderator needed for lldb-commits

Hi Tanya, I'd be happy to take care of this! Cheers, Jonas > On Jul 6, 2018, at 6:01 PM, Tanya Lattner via lldb-dev > wrote: > > LLDB Developers, > > Moderators are needed for the lldb-commits mailing list. Is anyone interested > in helping out? > > Thanks, > Tanya > ___

[lldb-dev] [RFC] LLDB Reproducers

Hi everyone, We all know how hard it can be to reproduce an issue or crash in LLDB. There are a lot of moving parts and subtle differences can easily add up. We want to make this easier by generating reproducers in LLDB, similar to what clang does today. The core idea is as follows: during normal

Re: [lldb-dev] [RFC] LLDB Reproducers

otocol. Because we capture and replay this, we can reproduce without running the executable, which is particularly convenient when you were originally debugging something on a different device for example. > > On Wed, Sep 19, 2018 at 6:50 AM, Jonas Devlieghere via lldb-dev > mailto:lldb

Re: [lldb-dev] skip some tests with "check-lldb"

When using lit as the driver (which is the case for check-lldb), the test granularity is at file-level: lit invokes dotest.py for every test file. You should be able to specify files to skip with lit's --filter. With regards to threading, lit will schedule one instance of dotest.py on every threa

Re: [lldb-dev] skip some tests with "check-lldb"

> On Sep 20, 2018, at 2:25 PM, Gábor Márton wrote: > > Hi Jonas, > > Thanks for the clarification. > Finally I could skip some of the tests by using a negative lookahead > regex passed to --filter. I wouldn't say that this is so convenient > and easy to overview, but works. > For example, to sk

Re: [lldb-dev] "devirtualizing" files in the VFS

HI Sam, Thanks again for taking the time to discuss this. > On Nov 15, 2018, at 3:02 AM, Sam McCall wrote: > > I'd like to get some more perspectives on the role of the VirtualFileSystem > abstraction in llvm/Support. > (The VFS layer has recently moved from Clang to LLVM, so crossposting to

Re: [lldb-dev] [cfe-dev] "devirtualizing" files in the VFS

> On Nov 15, 2018, at 3:34 AM, Whisperity wrote: > > I am really not sure if adding real file system functionality strictly into > the VFS is a good approach. This "ExternalFileSystem" thing sounds weird to > me. The `ExternalFileSystem` was an attempt to provide a more limited interface wh

Re: [lldb-dev] [cfe-dev] "devirtualizing" files in the VFS

Hi Sam, Does extending the status with a path sound reasonable? This would work similar to the current Name field, which is controlled by UseExternalName. Please let me know what you think. Thanks, Jonas > On Nov 15, 2018, at 10:10 AM, Jonas Devlieghere via cfe-dev > wrote: > > >> On Nov

[lldb-dev] The lit test driver gets killed because of SIGHUP

Hi everyone, Since we switched to lit as the test driver we've been seeing it getting killed as the result of a SIGHUP signal. The problem doesn't reproduce on every machine and there seems to be a correlation between number of occurrences and thread count. Davide and Raphael spent some time

Re: [lldb-dev] The lit test driver gets killed because of SIGHUP

ther than debugserver sending signal 17 (SIGSTOP) to the inferior. This makes me think that the signal might be coming from the kernel? > On Tue, Dec 4, 2018 at 6:49 PM Jonas Devlieghere via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >> Hi everyone, >> >> Since w

Re: [lldb-dev] The lit test driver gets killed because of SIGHUP

there was nothing interesting other than debugserver sending >> signal 17 (SIGSTOP) to the inferior. This makes me think that the signal >> might be coming from the kernel? >> >> >>> On Tue, Dec 4, 2018 at 6:49 PM Jonas Devlieghere via lldb-dev < >>> lldb-de

Re: [lldb-dev] The lit test driver gets killed because of SIGHUP

fires on the signal. > > - Raphael > Am Mi., 5. Dez. 2018 um 10:25 Uhr schrieb Pavel Labath via lldb-dev > : > > > > On 05/12/2018 03:49, Jonas Devlieghere via lldb-dev wrote: > > > Hi everyone, > > > > > > Since we switched to lit as the test

Re: [lldb-dev] The lit test driver gets killed because of SIGHUP

On Wed, Dec 5, 2018 at 9:45 AM Pavel Labath wrote: > On 05/12/2018 18:36, Jonas Devlieghere wrote: > > I believe that posix doesn't make this guarantee, but that in reality > > neither linux nor darwin recycles pids before they wrap around? > > Yes, linux tries pretty hard to not recycle pids, bu

[lldb-dev] [RFC] Using Sphinx to generate documentation

Hi everyone, The current LLDB website is written in HTML which is hard to maintain. We have quite a bit of HTML code checked in which can make it hard to differentiate between documentation written by us and documentation generated by a tool. Furthermore I think text/RST files provide a lower b

Re: [lldb-dev] [RFC] Using Sphinx to generate documentation

> On Dec 7, 2018, at 4:37 AM, Bruce Mitchener via lldb-dev > wrote: > >> On Fri, Dec 7, 2018 at 6:11 PM Raphael Isemann via lldb-dev >> wrote: >> I think if we want to actually lower the entry barrier for >> contributing/fixing things on the website, then the server should do >> this. From wh

[lldb-dev] [Reproducers] SBReproducer RFC

Hi Everyone, In September I sent out an RFC [1] about adding reproducers to LLDB. Over the past few months, I landed the reproducer framework, support for the GDB remote protocol and a bunch of preparatory changes. There's still an open code review [2] for dealing with files, but that one is curre

Re: [lldb-dev] Signedness of scalars built from APInt(s)

If I understand the situation correctly I think we should do both. I'd start by doing (2) to improve the current behavior and add a constructor for APSInt. We can then audit the call sites and migrate to APSInt where it's obvious that the type is signed. That should match the semantics of both clas

Re: [lldb-dev] Signedness of scalars built from APInt(s)

On Fri, Jan 4, 2019 at 3:13 PM Zachary Turner wrote: > I don't think #2 is a correct change. Just because the sign bit is set > doesn't mean it's signed. Is the 4-byte value 0x1000 signed or > unsigned? It's a trick question, because there's not enough information! > If it was written "int

Re: [lldb-dev] [Reproducers] SBReproducer RFC

On Mon, Jan 7, 2019 at 1:40 AM Pavel Labath wrote: > On 04/01/2019 22:19, Jonas Devlieghere via lldb-dev wrote: > > Hi Everyone, > > > > In September I sent out an RFC [1] about adding reproducers to LLDB. > > Over the > > past few months, I landed the reproduc

Re: [lldb-dev] [Reproducers] SBReproducer RFC

> If there is interest I can try to take a deeper look into the topic > sometime later but I hope that those initial thoughts are useful. > Thank you. I'll start by incorporating the feedback and ping the thread when the patch is ready for another look. > Tamas > > On

Re: [lldb-dev] [Reproducers] SBReproducer RFC

On Tue, Jan 8, 2019 at 8:27 AM Frédéric Riss wrote: > > > > On Jan 8, 2019, at 1:25 AM, Pavel Labath wrote: > > > > On 07/01/2019 22:45, Frédéric Riss wrote: > >>> On Jan 7, 2019, at 11:31 AM, Pavel Labath via lldb-dev < > lldb-dev@lists.llvm.org > wrote: > >>> >

Re: [lldb-dev] [RFC] Using Sphinx to generate documentation

ks for the heads up Stefan. This should be fine, I'll copy over your change in the rst files. > Best > Stefan > > On 6. Dec 2018, at 18:02, Jonas Devlieghere via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > Hi everyone, > > The current LLDB website is wri

Re: [lldb-dev] [RFC] Using Sphinx to generate documentation

ates on the build page. Hope this >> doesn't get in conflict with your work? >> > > Thanks for the heads up Stefan. This should be fine, I'll copy over your > change in the rst files. > > >> Best >> Stefan >> >> On 6. Dec 2018, at 1

Re: [lldb-dev] [Reproducers] SBReproducer RFC

Before I got around to coding this up I realized you can't take the address of constructors in C++, so the function address won't work as an identifier. On Tue, Jan 8, 2019 at 9:28 AM Jonas Devlieghere wrote: > On Tue, Jan 8, 2019 at 8:27 AM Frédéric Riss wrote: > >> >> >> > On Jan 8, 2019, at

Re: [lldb-dev] [Reproducers] SBReproducer RFC

On Wed, Jan 9, 2019 at 5:05 AM Pavel Labath wrote: > On 08/01/2019 21:57, Jonas Devlieghere wrote: > > Before I got around to coding this up I realized you can't take the > > address of constructors in C++, so the function address won't work as an > > identifier. > > > > You gave up way too easil

Re: [lldb-dev] [RFC] Using Sphinx to generate documentation

rote: >> >>> Hi Jonas, I think this is a great effort. Thanks! >>> >>> My current reviews do some small updates on the build page. Hope this >>> doesn't get in conflict with your work? >>> >> >> Thanks for the heads up Stefan. This sho

Re: [lldb-dev] [Reproducers] SBReproducer RFC

On Wed, Jan 9, 2019 at 8:42 AM Pavel Labath wrote: > On 09/01/2019 17:15, Jonas Devlieghere wrote: > > > > > > On Wed, Jan 9, 2019 at 5:05 AM Pavel Labath > > wrote: > > > > On 08/01/2019 21:57, Jonas Devlieghere wrote: > > > Before I got around to coding this up

Re: [lldb-dev] [Reproducers] SBReproducer RFC

I've updated the patch with a new version of the prototype: https://reviews.llvm.org/D56322 It uses Pavel's suggestion to use the function address as a runtime ID. All the deserialization code is generated using templates, with automatic mapping on indices during serialization and deserialization.

Re: [lldb-dev] [Reproducers] SBReproducer RFC

I've put up a (WIP) patch for the tool (https://reviews.llvm.org/D56822) in case anybody is curious about that. On Tue, Jan 15, 2019 at 1:41 PM Jonas Devlieghere wrote: > I've updated the patch with a new version of the prototype: > https://reviews.llvm.org/D56322 > > It uses Pavel's suggestion

Re: [lldb-dev] new tool (core2yaml) + a new top-level library (Formats)

Hi Pavel, On Tue, Mar 5, 2019 at 8:31 AM Pavel Labath via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Hello all, > > I have just posted a large-ish patch series for review (D58971, D58973, > D58975, D58976), and I want to use this opportunity to draw more > attention to it and highlight various

[lldb-dev] Can we remove this platform?

Yesterday I stumbled upon the initialization code for the "Kalimba" platform. It looks like this was added in 2014 and never had any tests. If nobody is relying on this platform, I propose to remove it. Review: https://reviews.llvm.org/D59850 Thanks, Jonas

Re: [lldb-dev] Can we remove this platform?

s > intellectual property. > > best regards, > > David Earlam > Staff-Senior Engineer / Manager. > Software Development Tools. > Qualcomm Technologies International, Ltd. > > -Original Message- > From: lldb-dev On Behalf Of Pavel > Labath via lldb-dev

[lldb-dev] Bugzilla default-assignee vs default-cc

I was talking to one of the Bugzilla admins (Kristof) earlier today and he pointed out that the default assignee for lldb bugs in the lldb-dev list, and that it might be better to change that from default-assignee to default-cc. That way, when the bug gets assigned, the mailing list continues to ge

Re: [lldb-dev] Bugzilla default-assignee vs default-cc

n the latter, then +1 from me too. > - Raphael > > Am Fr., 12. Apr. 2019 um 10:33 Uhr schrieb Pavel Labath via lldb-dev > : > > > > On 12/04/2019 10:25, Jonas Devlieghere via lldb-dev wrote: > > > I was talking to one of the Bugzilla admins (Kristof) earlier today and &

Re: [lldb-dev] [RFC] Adding a clang-style LLVM.h (or, "Are you tired of typing 'llvm::' everywhere ?")

Hey Pavel, Sounds like a good idea. I don't have a strong opinion on this matter, but I'm always in favor of improving readability. Cheers, Jonas On Wed, Apr 17, 2019 at 3:38 AM Pavel Labath via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Hello all, > > some llvm classes, are so well-known and

[lldb-dev] LLDB Website

Hey Tanya, Thanks again for migrating the LLDB website so it is generated with Sphinx! I made a change yesterday that hasn't been propagated yet. It looks like it might have something to do with http://lists.llvm.org/pipermail/www-scripts/2019-April/007524.html. Also, as the result of this chang

Re: [lldb-dev] Where did the python/c++ API documentation go?

Yep, I sent http://lists.llvm.org/pipermail/lldb-dev/2019-April/014992.html on Friday. It's unfortunate that the website isn't updating either, because I added some instructions on how to generate the docs locally, as an alternative to what Jim suggested. https://reviews.llvm.org/rGf7f03622eca68d

Re: [lldb-dev] LLDB Website

Friendly ping. There's a bunch of people that are annoyed by the missing documentation. I've already addressed most of the other comments about the broken URLs and missing top level links, but unfortunately that doesn't take effect because the website isn't updating. On Fri, Apr 19, 2019 at 12:17

Re: [lldb-dev] LLDB Website

Hey Tanya, On Tue, Apr 23, 2019 at 11:51 Tanya Lattner wrote: > Jonas, > > Ignore what I said before as these do need to be separate targets. It > appears the new targets are running doxygen. This isn’t something we > typically do as a post commit hook since it takes awhile. I’ll need to do > th

Re: [lldb-dev] LLDB Website

On Tue, Apr 23, 2019 at 5:00 PM Tanya Lattner wrote: > > > On Apr 23, 2019, at 11:54 AM, Jonas Devlieghere > wrote: > > Hey Tanya, > > On Tue, Apr 23, 2019 at 11:51 Tanya Lattner wrote: > >> Jonas, >> >> Ignore what I said before as these do need to be separate targets. It >> appears the new ta

Re: [lldb-dev] LLDB Website

On Tue, Apr 23, 2019 at 5:43 PM Tanya Lattner wrote: > > > On Apr 23, 2019, at 5:06 PM, Jonas Devlieghere > wrote: > > > > On Tue, Apr 23, 2019 at 5:00 PM Tanya Lattner > wrote: > >> >> >> On Apr 23, 2019, at 11:54 AM, Jonas Devlieghere >> wrote: >> >> Hey Tanya, >> >> On Tue, Apr 23, 2019 at

Re: [lldb-dev] LLDB Website

On Tue, Apr 23, 2019 at 6:04 PM Jonas Devlieghere wrote: > > > On Tue, Apr 23, 2019 at 5:43 PM Tanya Lattner > wrote: > >> >> >> On Apr 23, 2019, at 5:06 PM, Jonas Devlieghere >> wrote: >> >> >> >> On Tue, Apr 23, 2019 at 5:00 PM Tanya Lattner >> wrote: >> >>> >>> >>> On Apr 23, 2019, at 11:54

Re: [lldb-dev] LLDB Website

> Labath > > via lldb-dev > > Sent: Wednesday, April 24, 2019 1:16 AM > > To: Jonas Devlieghere ; Tanya Lattner > > > > Cc: LLDB > > Subject: [EXT] Re: [lldb-dev] LLDB Website > > > > On 24/04/2019 03:19, Jonas Devlieghere via lldb-dev wro

Re: [lldb-dev] LLDB Website

gt; ${CMAKE_CURRENT_BINARY_DIR}/../../../lib${LLVM_LIBDIR_SUFFIX}/python2.7/site-packages >> COMMENT "Generating LLDB Python API reference with epydoc" VERBATIM >> ) >> endif(EPYDOC_EXECUTABLE) >> >> >> > -Original Message----- >>

Re: [lldb-dev] LLDB Website

TORY >>> ${CMAKE_CURRENT_BINARY_DIR}/../../../lib${LLVM_LIBDIR_SUFFIX}/python2.7/site-packages >>> COMMENT "Generating LLDB Python API reference with epydoc" VERBATIM >>> ) >>> endif(EPYDOC_EXECUTABLE) >>> >>> >&g

Re: [lldb-dev] LLDB Website

t; WORKING_DIRECTORY >>>> ${CMAKE_CURRENT_BINARY_DIR}/../../../lib${LLVM_LIBDIR_SUFFIX}/python2.7/site-packages >>>> COMMENT "Generating LLDB Python API reference with epydoc" >>>> VERBATIM >>>> ) >>>> endif(EPYDOC_E

Re: [lldb-dev] LLDB Website

lldb >>>> -o ${CMAKE_CURRENT_BINARY_DIR}/python_reference >>>> --name "LLDB python API" >>>> --url "http://lldb.llvm.org"; >>>> ${EPYDOC_OPTIONS} >>>> DEPENDS swig_wrapper liblldb >

Re: [lldb-dev] LLDB Website

;>> #set(ENV{PYTHONPATH} >>>>> ${CMAKE_CURRENT_BINARY_DIR}/../../../lib/python2.7/site-packages) >>>>> add_custom_target(lldb-python-doc >>>>> ${EPYDOC_EXECUTABLE} >>>>> --html >>>>> ll

Re: [lldb-dev] LLDB Website

>>>> >>>>>> if(EPYDOC_EXECUTABLE) >>>>>> find_program(DOT_EXECUTABLE dot) >>>>>> if(DOT_EXECUTABLE) >>>>>> set(EPYDOC_OPTIONS ${EPYDOC_OPTIONS} --graph all --dotpath >>>>>> ${DOT_EXECUTABLE

[lldb-dev] [RFC] Removing lldb-mi

Hi everyone, After long consideration, I want to propose removing lldb-mi from the repository. It is basically unmaintained, doesn't match the LLDB code style, and worst of all the tests are unreliable if not already disabled. As far as I can tell it's missing core functionality to be usable from

Re: [lldb-dev] [Docs] Unify build instructions

Hey Stefan, > On Jul 3, 2019, at 3:29 PM, Stefan Gränitz wrote: > > Hey Jonas, thanks for the initiative! I actually started doing the same today > but then go distracted. Your changes certainly put it in a much better shape! > Before touching anything again, maybe it's worth some feedback firs

Re: [lldb-dev] [RFC] Removing lldb-mi

Thank you for doing this, Raphael. I believe this shows that it's possible to keep lldb-mi alive, without today's maintenance burden on the LLDB community, a solution that seems to appease everyones concerns in this thread. I hope this sparks interest for somebody to step up as a maintainer. I wen

[lldb-dev] LLDB BoF @ LLVM Dev Meeting

Hey everyone, I'm proposing an LLDB BoF at the upcoming LLVM developer meeting. Currently I have a pretty generic abstract, but I think it would be good to have a more concrete agenda. > LLDB has seen an influx of contributions over the past year, with the highest level of activity we've seen in

Re: [lldb-dev] Cannot use system debugserver for testing

I this was because of a change in llvm which broke codesigning of debugserver: https://reviews.llvm.org/D64965 On Fri, Jul 19, 2019 at 10:36 AM Gábor Márton via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Actually, it is embarrassing (perhaps for macOS and not for me) that after > a reboot the p

Re: [lldb-dev] test suite issue with Python2.7/3.5

The 7.0 branch is not compatible with Python 3, at least not if you're not on Windows. The first release that is, would be 9.0, which is currently being qualified. This includes a bunch of compatibility fixes, and a newer version of the vendored pexpect (4.6). As you've noticed, using different ver

Re: [lldb-dev] How do I use lit to only run the lldb test suite, now that dotest multiprocessing capabilities have been removed?

Hey Ted, 1. You can run just the dotest-tests by pointing lit at the `lit/Suite` directory. 2. You can pass arguments to dotest by passing `dotest-args` in --param. The invocation would look something like this: /path/to/llvm/bin/llvm-lit /path/to/lldb/lit/Suite --param 'dotest-args=--foo --bar'

Re: [lldb-dev] How do I use lit to only run the lldb test suite, now that dotest multiprocessing capabilities have been removed?

Hey Ted, On Thu, Aug 8, 2019 at 2:08 PM Ted Woodward wrote: > > Thanks Jonas. > > Is full support for --param fairly recent? I tried it with a version of our > master, based on top-of-tree from about a month ago, and it didn't work quite > right. It's passing the dotest args, but it's also gene

Re: [lldb-dev] How do I use lit to only run the lldb test suite, now that dotest multiprocessing capabilities have been removed?

So far the only thing that changed by removing multiprocess is that `--no-multiprocess` is always enabled. Everything else you describe is still possible, and will continue to be possible. Even when we remove the driver functionality from dotest.py this will all continue to work. The only differen

Re: [lldb-dev] Who sets the 10-minute timeouts?

As a workaround, assuming you're running the tests with lit, you should be able to override the timeout with --max-time. On Wed, Aug 14, 2019 at 4:15 PM Adrian McCarthy via lldb-dev wrote: > > > > On Wed, Aug 14, 2019 at 2:47 PM Jim Ingham wrote: >> >> >> >> > On Aug 14, 2019, at 1:41 PM, Adrian

Re: [lldb-dev] [patch] char8_t support (plus dlang UTF8/16/32)

Hi James, Thanks for working on this. I've opened a code review for your patch: https://reviews.llvm.org/D66447 I've had to make some modification for it to compile and added a test. Cheers, Jonas On Sun, Aug 18, 2019 at 6:34 PM James Blachly via lldb-dev wrote: > > Dear LLDB developers: > > I

Re: [lldb-dev] Anybody using the GUI?

Hi Greg, We're more than a year later and I haven't seen any development on the GUI. While I personally thing this could be a really cool feature, I've never been able to use it because it's missing too many thing to be useful for now. When I talk to people that know about this feature, I hear eit

Re: [lldb-dev] [RFC] Restructuring the (command) tests

Sounds good to me :-) On Fri, Aug 30, 2019 at 1:27 PM Davide Italiano via lldb-dev wrote: > > On Fri, Aug 30, 2019 at 1:44 AM Raphael “Teemperor” Isemann via > lldb-dev wrote: > > > > Hi all, > > > > I have to admit I’m getting a bit confused lately where to put tests. > > Especially for testin

Re: [lldb-dev] Rust support in LLDB, again

Hi Vadim, On Sat, Sep 28, 2019 at 4:00 PM Vadim Chugunov via lldb-dev wrote: > > Hi, > Last year there was an effort led by Tom Tromey to add Rust language support > into LLDB. He had implemented a fairly complete language plugin, however it > was not accepted into mainline because of supporta

Re: [lldb-dev] issue with lldb9 and python3.5

Yes, Python 3.5 is not supported. We "officially" support Python 2.7 and Python 3.7. I'm sorry if we forgot that in the release notes. On Mon, Oct 28, 2019 at 7:06 AM Tom Stellard via lldb-dev wrote: > > + lldb-dev > > On 10/28/2019 07:06 AM, Tom Stellard wrote: > > On 10/28/2019 03:50 AM, Romari

Re: [lldb-dev] issue with lldb9 and python3.5

On Mon, Oct 28, 2019 at 9:32 AM Tom Stellard wrote: > > On 10/28/2019 09:29 AM, Jonas Devlieghere wrote: > > Yes, Python 3.5 is not supported. We "officially" support Python 2.7 > > and Python 3.7. I'm sorry if we forgot that in the release notes. > > > > Is there a specific reason why 3.5 is not

Re: [lldb-dev] issue with lldb9 and python3.5

On Mon, Oct 28, 2019 at 10:04 AM Jonas Devlieghere wrote: > > On Mon, Oct 28, 2019 at 9:32 AM Tom Stellard wrote: > > > > On 10/28/2019 09:29 AM, Jonas Devlieghere wrote: > > > Yes, Python 3.5 is not supported. We "officially" support Python 2.7 > > > and Python 3.7. I'm sorry if we forgot that i

Re: [lldb-dev] [cfe-dev] RFC: Using GitHub Actions for CI testing on the release/* branches

Hey Tom, That sounds really useful. Would it be possible to include LLDB as well? We have a subset of tests (unit & lit) that can be run without Python/SWIG by passing LLDB_DISABLE_PYTHON=ON to CMake. Thanks, Jonas On Tue, Nov 12, 2019 at 2:35 AM Hans Wennborg via cfe-dev wrote: > > On Tue, Nov

Re: [lldb-dev] Segfault using the lldb python module with a non-Xcode python binary

Hey António, If I understand correctly, you're trying to mix between two versions of the Python interpreter and library. That's not something that's supported and has always been an issue. Internally we get the occasional bug report where somebody install python via homebrew or python.org and the

Re: [lldb-dev] Segfault using the lldb python module with a non-Xcode python binary

I've put up a patch to extend the documentation: https://reviews.llvm.org/D70252 Please have a look let me know if you have any comments or suggestions! On Thu, Nov 14, 2019 at 9:17 AM Jonas Devlieghere wrote: > > Hey António, > > If I understand correctly, you're trying to mix between two versi

Re: [lldb-dev] LLDB Website is not being updated

I see a bunch of eros here: http://lists.llvm.org/pipermail/www-scripts/2019-November/thread.html Is this possibly related to the Github/monorepo transition? -- Jonas On Thu, Nov 21, 2019 at 10:52 AM Adrian Prantl via lldb-dev wrote: > > Hello Tanya, > > it looks like the cron job that is suppo

[lldb-dev] [RFC] Supporting Lua Scripting in LLDB

Hi everyone, Earlier this year, when I was working on the Python script interpreter, I thought it would be interesting to see what it would take to support other scripting languages in LLDB. Lua, being designed to be embedded, quickly came to mind. The idea remained in the back of my head, but I n

Re: [lldb-dev] [RFC] Supporting Lua Scripting in LLDB

o you do for people that want only Lua? They might still want to re-implement some data formatters they care about... Anyway, given that we don't maintain/ship data formatters in Python ourselves, maybe this isn't that big of an issue at all? > On 09/12/2019 01:25, Jonas Devlieghere via

Re: [lldb-dev] [RFC] Supporting Lua Scripting in LLDB

e same data formatter implemented in both > scripting languages. Mixing scripting languages makes sense for when > your LLDB is configured to support both Python and Lua, but what do > you do for people that want only Lua? They might still want to > re-implement some data formatters they care ab

[lldb-dev] Optional Dependencies in LLDB

Hey everyone, I just wanted to let you know that most of the work is complete for auto-detecting optional dependencies in LLDB. Unless explicitly specified, optional dependencies like editline will be enabled when available and disabled otherwise. This is different from the old behavior, where op

[lldb-dev] Fwd: [Lldb-commits] Optional Dependencies in LLDB

Hey Greg, On Mon, Jan 6, 2020 at 12:28 PM Greg Clayton wrote: > > editline seems like a bad example as being optional as I wouldn't want to use > a LLDB that doesn't have editline support. Or are we taking care of this by > having the cmake settings files (lldb/cmake/caches/*.cmake) for each sy

Re: [lldb-dev] Optional Dependencies in LLDB

On Tue, Jan 7, 2020 at 12:52 PM Martin Storsjö wrote: > > On Mon, 6 Jan 2020, Jonas Devlieghere via lldb-dev wrote: > > > I just wanted to let you know that most of the work is complete for > > auto-detecting optional dependencies in LLDB. Unless explicitly > > speci

Re: [lldb-dev] Optional Dependencies in LLDB

Tue, Jan 7, 2020 at 12:52 PM Martin Storsjö wrote: > > > > On Mon, 6 Jan 2020, Jonas Devlieghere via lldb-dev wrote: > > > > > I just wanted to let you know that most of the work is complete for > > > auto-detecting optional dependencies in LLDB. Unless explici

Re: [lldb-dev] Optional Dependencies in LLDB

Yes, that's correct. This was added in edadb818e5b. On Tue, Jan 7, 2020 at 11:19 PM Martin Storsjö wrote: > > On Tue, 7 Jan 2020, Jonas Devlieghere wrote: > > > After trying it out I concluded that it should be easy enough to check > > for the static bindings flag in FindPythonInterpAndLibs.cmake

Re: [lldb-dev] Optional Dependencies in LLDB

On Wed, Jan 8, 2020 at 2:46 PM Adrian Prantl wrote: > > > > > On Jan 6, 2020, at 11:17 AM, Jonas Devlieghere via lldb-dev > > wrote: > > > > Hey everyone, > > > > I just wanted to let you know that most of the work is complete for > > a

Re: [lldb-dev] How/where to add test cases in LLDB.

Hey Sourabh, You'll want to take a look at the existing tests in `test/Shell`. These tests run one or more shell commands and uses FileCheck to verify that the output match what you expect. These tests use lldb's batch mode, where lldb commands are executed one after another, rather than interacti

Re: [lldb-dev] Moving lldbsuite API tests

I'm very excited about this. Thank you for taking the time and effort to make this happen! On Mon, Feb 10, 2020 at 9:01 AM Jordan Rupprecht wrote: > > Later today I'm planning to land D71151, which moves > lldb/packages/Python/lldbsuite/test to lldb/test/API, and removes the > lldb/test/API/tes

Re: [lldb-dev] LLDB_PYTHON_HOME

Hey Adrian, Config.h gets generated by expanding the corresponding CMake variables. If you look at LLDBConfig.cmake, you can see that LLDB_PYTHON_HOME is computed from PYTHON_EXECUTABLE. The problem appears that somehow CMake ignored your specified PYTHON_HOME and decided to pick a different Pytho

Re: [lldb-dev] LLDB_PYTHON_HOME

On Thu, Feb 27, 2020 at 10:53 AM Adrian McCarthy wrote: > Thanks for the info. Setting Python3_ROOT_DIR solves the problem. > > Looking at the cmake output from before setting Python3_ROOT_DIR, cmake > looks for Python twice and finds it at the two different locations. > > Early on: > > -- Found

Re: [lldb-dev] LLDB_PYTHON_HOME

So to make my previous explanation more concrete: On Thu, Feb 27, 2020 at 11:05 AM Jonas Devlieghere wrote: > > > On Thu, Feb 27, 2020 at 10:53 AM Adrian McCarthy > wrote: > >> Thanks for the info. Setting Python3_ROOT_DIR solves the problem. >> >> Looking at the cmake output from before setti

Re: [lldb-dev] LLDB Website is not being updated

Hey Adrian, The version is hard-coded in lldb/docs/conf.py, we just need to update it there. As far as I know the website is being updated nightly. Cheers, Jonas On Mon, Mar 2, 2020 at 1:41 PM Adrian Prantl wrote: > Hello Tanya, > > I just looked at the LLDB website and it still displays the o

Re: [lldb-dev] LLDB Website is not being updated

I removed the version number from the home page. To github.com:llvm/llvm-project.git adc69729ec8..c77fc00eec0 master -> master I'm not sure we should have the banner because (1) the documentation doesn't change as much as llvm/clang and (2) we don't archive the old documentation so there's no

Re: [lldb-dev] lldb-instr not working

Hi Walter, lldb-instr needs compile_commands.json file to figure out the exact compiler invocation for every file. Can you verify that the file exists in the directory you're running lldb-instr from? Cheers, Jonas On Mon, Mar 23, 2020 at 1:29 PM Walter via lldb-dev wrote: > Hi, I've recently t

[lldb-dev] [RFC] Upstreaming Reproducer Capture/Replay for the API Test Suite

Hi everyone, Reproducers in LLDB are currently tested through (1) unit tests, (2) dedicated end-to-end shell tests and (3) the `lldb-check-repro` suite which runs all the shell tests against a replayed reproducer. While this already provides great coverage, we're still missing out on about 800 API

Re: [lldb-dev] Minimum required swig version?

On Thu, Apr 16, 2020 at 2:42 PM Davidino Italiano via lldb-dev < lldb-dev@lists.llvm.org> wrote: > > > On Apr 16, 2020, at 2:28 PM, Ted Woodward via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > http://lldb.llvm.org/resources/build.html Says we need swig 2 or later: > > If you want to run the t

Re: [lldb-dev] Break setting aliases...

I don't mind adding the two-letter commands, but I also don't really see the value in being able to say `bs` instead of `b s -y`. Until either becomes muscle memory, both require a little cognitive overhead of thinking "breakpoint set -y" or "breakpoint source". As a user there would be more value

Re: [lldb-dev] Deprecating Python2 and adding type-annotations to the python API

Hi Nathan, Thanks for bringing this up. I've been expecting this question for a while now. Python 2 is end-of-life and we should move to Python 3. I'm pretty sure nobody here disagrees with that. Unfortunately though, we still have consumers, both internally and externally, that still rely on it.

  1   2   >