Re: [lldb-dev] Is GetLogIf**All**CategoriesSet useful?

> On Jan 19, 2022, at 10:25 AM, Jim Ingham wrote: > > > >> On Jan 19, 2022, at 6:40 AM, Pavel Labath wrote: >> >> Hi all, >> >> In case you haven't noticed, I'd like to draw your attention to the >> in-flight patches (https://reviews.llvm.org/D117382, >>

Re: [lldb-dev] [llvm-dev] [RFC] Building LLVM-Debuginfod

+lldb-dev On Mon, Oct 4, 2021 at 11:01 PM Petr Hosek via llvm-dev < llvm-...@lists.llvm.org> wrote: > Two major factors are compatibility with a broad range of platforms (our > toolchain is already being used by developers on Linux, macOS, Windows) and > permissive license (our goal is to

[lldb-dev] LLDB Reproducers

Hey everyone, Over the course of the past year, I've come to the conclusion that the reproducers still require a non-trivial amount of investment to reach production quality. Unfortunately, I don't have the bandwidth to make that happen. Reproducers are inherently all-or-nothing: they either

Re: [lldb-dev] Removing linux mips support

+1 This all sounds in line with the expectations we've laid out on the mailing list in the past for platform/language support. On Tue, Mar 9, 2021 at 12:24 AM Pavel Labath via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Hi all, > > I propose to remove support for linux mips debugging. This

Re: [lldb-dev] Updating or removing lldb's copy of unittest2

Hey David, On Thu, Jan 28, 2021 at 2:46 AM David Spickett via lldb-dev < lldb-dev@lists.llvm.org> wrote: > I came across a minor bug writing some lldb-server tests where single > line diffs weren't handled correctly by unittest2. Turns out they are > in the latest version but the third_party/

Re: [lldb-dev] [RFC] Moving away from epydoc for the LLDB SB API documentation

Another issue with epydoc is that it currently doesn't list properties. The checked-in documentation from the old days had them, but I never got epydoc to generate them (and to be fair I never really tried). Instead I looked at alternatives as well. The main issue I found is that it's easy to

Re: [lldb-dev] [RFC] Segmented Address Space Support in LLDB

work with plain addresses, and where the added address space >>> would be a nuisance (or a source of bugs). E.g. ELF has no notion of address >>> space, so I don't think I'd find it helpful to replace all plain integer >>> calculations >>> in elf parsing code w

Re: [lldb-dev] Deleting lldb/utils/test/

Last time I looked at these nothing seemed relevant (anymore) to me either. I'm in favor of getting rid of the directory. On Tue, Oct 27, 2020 at 10:26 AM Vedant Kumar via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Hi, > > I'm considering deleting the lldb/utils/test/ directory as a cleanup.

[lldb-dev] [RFC] Segmented Address Space Support in LLDB

We want to support segmented address spaces in LLDB. Currently, all of LLDB’s external API, command line interface, and internals assume that an address in memory can be addressed unambiguously as an addr_t (aka uint64_t). To support a segmented address space we’d need to extend addr_t with a

Re: [lldb-dev] [llvm-dev] HTTP library in LLVM

On Mon, Aug 31, 2020 at 4:38 PM Petr Hosek via llvm-dev < llvm-...@lists.llvm.org> wrote: > There are several options, I've looked at couple of them and the one I > like the most so far is https://github.com/yhirose/cpp-httplib for a few > reasons: > > * It's MIT licensed. > * It supports Linux,

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

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] 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

[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

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

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

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

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

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: > > --

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

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 >

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

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] 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

Re: [lldb-dev] Optional Dependencies in LLDB

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 &

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

[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

[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

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

xing 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 about... Anyway, given > that we don't maintain/ship data formatters

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

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 lldb-dev wrote: > > Hi everyone, > > > > Earlier this ye

[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

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

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

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] [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,

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

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

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,

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

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

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

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: > >

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

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

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

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

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

[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] [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

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

[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] LLDB Website

t;>>> find_program(DOT_EXECUTABLE dot) >>>>>> if(DOT_EXECUTABLE) >>>>>> set(EPYDOC_OPTIONS ${EPYDOC_OPTIONS} --graph all --dotpath >>>>>> ${DOT_EXECUTABLE}) >>>>>> endif() >>>>>> set(D

Re: [lldb-dev] LLDB Website

${CMAKE_CURRENT_BINARY_DIR}/../../../lib/python2.7/site-packages) >>>>> add_custom_target(lldb-python-doc >>>>> ${EPYDOC_EXECUTABLE} >>>>> --html >>>>> lldb >>>>> -o ${CMAKE_CURRENT_BINARY_DIR}/python_refere

Re: [lldb-dev] LLDB Website

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

Re: [lldb-dev] LLDB Website

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

Re: [lldb-dev] LLDB Website

INARY_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

Y_DIR}/../../../lib${LLVM_LIBDIR_SUFFIX}/python2.7/site-packages >> COMMENT "Generating LLDB Python API reference with epydoc" VERBATIM >> ) >> endif(EPYDOC_EXECUTABLE) >> >> >> > -Original Message- >> > From: lldb-dev On B

Re: [lldb-dev] LLDB Website

t; 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 wrote: > > > &

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

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 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

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 >

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

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.

[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

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

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

hen +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 > >

[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

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

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 > Sent: 27 Ma

[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] 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

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] [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

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

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

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] [RFC] Using Sphinx to generate documentation

e 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 18:02, Jonas Devlieghere via lldb-dev <

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] [Reproducers] SBReproducer RFC

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 Mon, Jan 7, 2019 at 9:40 AM Pavel Labath wrote:

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] 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

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

[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

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

[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

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,

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

s 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 driv

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

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

[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] [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

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

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] 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

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

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

[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

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 >

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 >

[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:

  1   2   >