Re: [lldb-dev] [3.8 Release] Release status

On Thu, Feb 18, 2016 at 4:22 PM, Hans Wennborg wrote: > According to the schedule (e.g. on the right on llvm.org), we should > have tagged the release by now, but we haven't, so we're officially > behind schedule. I'm still optimistic that we can wrap this up pretty > soon,

Re: [lldb-dev] [llvm-dev] LLVM GSOC Projects Criteria Consultation (before 2/28)

On Thu, Feb 16, 2017 at 10:16 PM, Mehdi Amini via llvm-dev wrote: > Hello all, > > GSOC is around the corner, and the LLVM projects plans to participate again > this year. For those who don’t know about GSOC, students are proposing a > project that they will work on for 3

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

Jason probably knows about the crash hook. On Tue, Dec 19, 2017 at 4:24 AM, Pavel Labath wrote: > 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

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

Pavel, I happened to hit this. I'm not 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

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

Yes, it seems `configuration.compiler` is None, so this explodes: [...] if not is_exe(configuration.compiler): [...] On Fri, Oct 27, 2017 at 12:37 PM, Davide Italiano wrote: > I think that this change (or some change nearby) broke `check-lldb` on Fedora. > > I'm

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

On Fri, Oct 27, 2017 at 12:52 PM, Ted Woodward wrote: > I think if clang exists in-tree, it should be used. If it doesn't, the > compiler used to build lldb should be used. > > Unless, of course, the compiler is specified with the cmake variables. > I think that if

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

Mind if I try to write a patch for this one or you want to do it? On Fri, Oct 27, 2017 at 12:56 PM, Pavel Labath wrote: > Yes, listing clang as a dependency sounds like a good idea. > > On 27 October 2017 at 12:45, Davide Italiano wrote: >> So, I wiped

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

r316800, thanks! On Fri, Oct 27, 2017 at 2:07 PM, Zachary Turner wrote: > One more nitpick. Can you make it a dependency of `check-lldb-lit` target > also? Just for the sake of pedantry. > > On Fri, Oct 27, 2017 at 2:04 PM Pavel Labath wrote: >> >> Ship

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

On Fri, Jan 26, 2018 at 8:38 AM, Erik Pilkington via lldb-dev wrote: > > > On 2018-01-25 1:58 PM, Greg Clayton wrote: >>> >>> On Jan 25, 2018, at 10:25 AM, Erik Pilkington >>> wrote: >>> >>> Hi, >>> I'm not at all familiar with LLDB, but I've

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

On Wed, Jan 17, 2018 at 12:32 PM, Adrian Prantl via lldb-dev wrote: > Hi lldb-dev! > > I've been investigating some spurious LLDB test suite failures on > http://green.lab.llvm.org/green/ that had to do with build artifacts from > previous runs lying around in the test

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

On Wed, Jan 17, 2018 at 1:02 PM, Davide Italiano wrote: > On Wed, Jan 17, 2018 at 12:32 PM, Adrian Prantl via lldb-dev > wrote: >> Hi lldb-dev! >> >> I've been investigating some spurious LLDB test suite failures on >>

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

On Wed, Jan 17, 2018 at 12:32 PM, Adrian Prantl via lldb-dev wrote: > Hi lldb-dev! > > I've been investigating some spurious LLDB test suite failures on > http://green.lab.llvm.org/green/ that had to do with build artifacts from > previous runs lying around in the test

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

I agree. I plan to remove the two backends (well, at least submit requests for) in 3 weeks from today. There are a lot of moving pieces right now and I'd really love for things to stabilize but also give people an opportunity to speak up, if they want to. -- Davide On Tue, Jan 30, 2018 at 5:30

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

On Thu, Feb 1, 2018 at 6:50 AM, Pavel Labath wrote: > 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

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

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 we are and what are some possible future directions for the projects, in terms of better

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

On Tue, Feb 6, 2018 at 8:18 AM, Pavel Labath <lab...@google.com> wrote: > On 6 February 2018 at 15:41, Davide Italiano <dccitali...@gmail.com> wrote: >> On Tue, Feb 6, 2018 at 7:09 AM, Pavel Labath <lab...@google.com> wrote: >>> On 6 February 2018 at 04:11, Dav

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

On Tue, Feb 6, 2018 at 7:09 AM, Pavel Labath <lab...@google.com> wrote: > On 6 February 2018 at 04:11, Davide Italiano via lldb-dev > <lldb-dev@lists.llvm.org> wrote: >> Hi, >> in the last couple of months a lot of people put a lot of attentions >> and energy

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

On Tue, Feb 6, 2018 at 7:09 AM, Pavel Labath <lab...@google.com> wrote: > On 6 February 2018 at 04:11, Davide Italiano via lldb-dev > <lldb-dev@lists.llvm.org> wrote: >> Hi, >> in the last couple of months a lot of people put a lot of attentions >> and energy

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

On Wed, Feb 7, 2018 at 7:57 AM, Pavel Labath wrote: > On 7 February 2018 at 14:20, Zachary Turner wrote: >> >> As someone who gave up on trying to set up a bot due to flakiness, I have a >> different experience. > > I did not say it was easy to get to the

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

On Wed, Feb 7, 2018 at 9:32 AM, Pavel Labath wrote: > 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

[lldb-dev] TestExprCompletion failing

Raphael, this test has been failing for a while. http://lab.llvm.org:8080/green/view/LLDB/job/lldb-cmake/9755/console Testing Time: 466.83s Failing Tests (1): lldb-Suite :: expression_command/completion/TestExprCompletion.py Can you please take a look? Thanks! --

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

Hi, during my wandering I stumbled upon the `Go` and the `Java` plugins in the lldb source tree. They seem to not have been touched in a while, and I'm not necessarily sure they're in a working state. Keeping them in tree is a maintenance burden, so unless somebody is actively using them or

Re: [lldb-dev] increase timeout for tests?

On Tue, Mar 13, 2018 at 11:26 AM, Jim Ingham wrote: > It sounds like we timing out based on the whole test class, not the > individual tests? If you're worried about test failures not hanging up the > test suite the you really want to do the latter. > > These are all tests

Re: [lldb-dev] increase timeout for tests?

On Mon, Mar 12, 2018 at 7:01 PM, Jim Ingham wrote: > The problem with having no timeouts is that you have to then be fairly > careful how you write tests. You can't do: > > while (1) { >print("Set a breakpoint here and hit it a few times then stop the test"); > } > >

Re: [lldb-dev] increase timeout for tests?

On Fri, Mar 9, 2018 at 3:45 AM, Pavel Labath wrote: > > > > On Thu, 8 Mar 2018 at 18:40, Davide Italiano wrote: >> >> On Thu, Mar 8, 2018 at 10:29 AM, Greg Clayton wrote: >> > It would be great to look into these and see what is

Re: [lldb-dev] increase timeout for tests?

On Tue, Mar 13, 2018 at 3:30 AM, Pavel Labath wrote: > I think we should get some data before pulling numbers out of our sleeves. > If we can get some numbers on the slowest machine that we have around, then > we should be able to specify the timeout as some multiple of the

Re: [lldb-dev] increase timeout for tests?

I'll re-run the test and send you a list. Thank you! -- Davide On Tue, Mar 13, 2018 at 9:02 AM, Pavel Labath wrote: > Aha, in that case, it definitely sounds like increasing the timeout is in > order. I would still go for something less than 30 minutes, but I don't care >

Re: [lldb-dev] increase timeout for tests?

On Thu, Mar 8, 2018 at 10:29 AM, Greg Clayton wrote: > It would be great to look into these and see what is taking so long. Some > tests are doing way too much work and should be split up. But it would be > great to see if we have any tests that are not good tests and are

Re: [lldb-dev] how do i submit my patch for 'Support demangling for D symbols via dlopen'

On Fri, Mar 9, 2018 at 12:44 AM, Timothee Cour via lldb-dev wrote: > I've registered to > http://lists.llvm.org/cgi-bin/mailman/subscribe/lldb-commits and sent > my patch via that email to lldb-comm...@lists.llvm.org but doesn't > appear yet on

[lldb-dev] Anybody using the GUI?

Good day. While trying to implement a command in lldb I noticed lldb has this awesome `gui` command that opens an ncurses GUI. I find it really useful and I wanted to play with it a bit, but I wasn't really able to get it working. In particular, I tried to press enter on `target create` or

Re: [lldb-dev] FileSpec and normalization questions

IIRC We have path normalization functions in llvm, have you looked at them? Thanks, -- Davide On Thu, Apr 19, 2018 at 11:14 AM, Greg Clayton via lldb-dev wrote: > We currently have DWARF that has a DW_AT_comp_dir that is set to "./" > followed by any number of extra

Re: [lldb-dev] Displaying custom types in STL containers

On Mon, Mar 19, 2018 at 6:04 PM, Florin Trofin via lldb-dev wrote: > Ok,but how do you debug this? Debugging the debugger's formatter seems > non-trivial. Are there any guides/steps? > I generally recommend enabling logs (through `log enable lldb -f ~/somefile.txt`) and

[lldb-dev] cmake incremental OSX is red

I'm currently bisecting, but this is a FYI (in case it's obvious to anybody) https://ci.swift.org/job/oss-lldb-incremental-osx-cmake/169/ = Issue Details = FAIL: test_expr_symbols_dsym (expression_command/test/TestExprs2.py) FAIL: test_expr_symbols_dwarf

Re: [lldb-dev] cmake incremental OSX is red

I'm not sure why it's failing, but it's probably > some silly typo. Unfortunately I don't have time to look at it today. > > I am hoping that the fix is obvious. If it's not, you can revert that patch, > and I'll check it out tomorrow. > > pl > > > On Tue, 20 Mar 2018 at 17:2

Re: [lldb-dev] how do i submit my patch for 'Support demangling for D symbols via dlopen'

On Mon, Feb 26, 2018 at 9:01 PM, Timothee Cour via lldb-dev wrote: > https://github.com/llvm-mirror/lldb/pull/3 > > it would be *really* nice if llvm or lldb accepted industry standard > github PR's, at least as an option. Would make contributing so much > easier for

Re: [lldb-dev] Adding D language demangling support

On Mon, Feb 26, 2018 at 8:45 PM, Timothee Cour via lldb-dev wrote: > I made it work: > https://github.com/llvm-mirror/lldb/pull/3 > (note: also requires the D plugin on D side which I can submit to > another repo separately, and which is small) > > not sure if lldb

[lldb-dev] DW_OP_deref handling

Hi Greg, I have this issue that I suspect is a bug in lldb’s handling of DW_OP_deref. I wasn’t able to craft an easy C++ testcase, so I’ll start from my motivating (swift) example. Given the following code: func use(_ t : T) {} func single(_ t : T) { let x = t use(x) } let s = "hello"

Re: [lldb-dev] DW_OP_deref handling

On Thu, Oct 11, 2018 at 11:16 AM Greg Clayton wrote: > > The issue is DW_OP_deref dereferences a pointer and pushes it onto the stack. > The code currently, for a load address that is on top of the stack does: > > Value::ValueType value_type = stack.back().GetValueType(); > switch (value_type) {

Re: [lldb-dev] DW_OP_deref handling

Follow up. This turned out to be a bug in the swift specific support, so I don't think the DWARF parser code is wrong here. Thanks! -- Davide On Thu, Oct 11, 2018 at 10:52 AM Davide Italiano wrote: > > Hi Greg, > I have this issue that I suspect is a bug in lldb’s handling of DW_OP_deref. > I

Re: [lldb-dev] DW_OP_deref handling

On Thu, Oct 11, 2018 at 1:38 PM Greg Clayton wrote: > > I am happy to look at any DWARF expressions you have and help figure out > where the change needs to go or how the expression need to be fixed. > Thank you for your help, it's greatly appreciated. hopefully we'll have a more precise

Re: [lldb-dev] [LLDB]{Proposal} Adding new typesystem to support language like PLI/COBOL to lldb

On Tue, Oct 9, 2018 at 3:56 AM Chirag Patel via lldb-dev wrote: > > Hello all, > > > > I am looking into adding the new typesystem support for languages like > PLI/COBOL. > > Is anybody actively working/looking on this? > > > > Regards, > > Not I'm aware of. -- Davide

Re: [lldb-dev] [LLD] How to get rid of debug info of sections deleted by garbage collector

On Wed, Sep 19, 2018 at 8:35 PM Venkata Ramanaiah Nalamothu via lldb-dev wrote: > > Hi, > > After compiling an example.cpp file with "-c -ffunction-sections" and linking > with "--gc-sections" (used ld.lld), I am still seeing debug info for the > sections deleted by garbage collector in the

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

On Fri, Jan 4, 2019 at 3:54 PM Zachary Turner wrote: > > It seems like we have 3 uses of this constructor in LLDB. > > IRInterpreter.cpp: Constructs a Scalar for an llvm::Constant. > IRForTarget.cpp: Constructs a Scalar for an llvm::Constant. > ClangASTContext.cpp: bitcasts an APFloat to an

Re: [lldb-dev] beginner bugs

On Sun, Dec 16, 2018 at 5:50 PM Davide Italiano wrote: > > [cross-posting this to llvm-dev for better visibility] > > I got a private mail from a student (prospective GSoC) who asked me > what was the best way to start contributing to lldb. So, I decided to > take some bugs and mark them as

Re: [lldb-dev] When should ArchSpecs match?

On Thu, Dec 6, 2018 at 3:20 PM Adrian Prantl via lldb-dev wrote: > > I was puzzled by the behavior of ArchSpec::IsExactMatch() and > IsCompatibleMatch() yesterday, so I created a couple of unit tests to > document the current behavior. Most of the tests make perfect sense, but a > few edge

Re: [lldb-dev] [cfe-dev] ASTImporter patches and improvements, please help

On Thu, Dec 6, 2018 at 6:39 AM Gábor Márton wrote: > > Hi Davide, > > Thank you for your email. > > > In particular, what's the error you get when lldb fails immediately running > > the tests? > > Also, have you checked libcxx and libcxx-abi in your build? We might > > consider making that a

Re: [lldb-dev] RFC: Simplifying SymbolFile interface

On Thu, Jan 10, 2019 at 12:43 AM Pavel Labath via lldb-dev wrote: > > On 09/01/2019 20:59, Zachary Turner via lldb-dev wrote: > > The Native PDB symbol file plugin I think is mostly complete. It's at > > least almost as good as the old Windows-only PDB plugin in 90% of ways, > > while actually

Re: [lldb-dev] LLDB bot health

On Fri, Jan 11, 2019 at 9:20 AM via lldb-dev wrote: > > Inspired by people recently asking about or filing bugs for test fails > that happen in their own environments, I thought I might do the same. > "But wait," I thought, "maybe some bots are already finding these." > > Which led me to

Re: [lldb-dev] LLDB bot health

On Fri, Jan 11, 2019 at 3:07 PM Stella Stamenova wrote: > > Thanks Davide, > > I think several of these bots have not been maintained for a while. One thing > we could do is try to ping the owners and see if it's possible to update the > bots or if they're no longer useful, then remove them. >

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

While adding support for 512-bit integers in `Scalar`, I figured I could add some coverage. TEST(ScalarTest, Signedness) { auto s1 = Scalar(APInt(32, 12, false /* isSigned */)); auto s2 = Scalar(APInt(32, 12, true /* isSigned */ )); ASSERT_EQ(s1.GetType(), Scalar::e_uint); // fails

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

On Fri, Jan 4, 2019 at 1:57 PM Davide Italiano wrote: > > While adding support for 512-bit integers in `Scalar`, I figured I > could add some coverage. > > TEST(ScalarTest, Signedness) { > auto s1 = Scalar(APInt(32, 12, false /* isSigned */)); > auto s2 = Scalar(APInt(32, 12, true /* isSigned

Re: [lldb-dev] apples, pears etc: how to use __builtin_availability() elsewhere?

On Thu, Sep 13, 2018 at 2:56 AM René J.V. Bertin via lldb-dev wrote: > > Hi, > > clang has this nice runtime OS version checker but I cannot seem to find if > this is useable anywhere except on Apple OSes. > For ObjC (and thus @available()) one can still argue that the language isn't > of much

Re: [lldb-dev] [RFC]The future of pexpect

On Fri, Feb 22, 2019 at 6:32 AM Pavel Labath wrote: > > On 21/02/2019 19:48, Ted Woodward wrote: > > > > > >> -Original Message- > >> From: lldb-dev On Behalf Of Pavel Labath > >> via lldb-dev > >> Sent: Thursday, February 21, 2019 8:35 AM > >> To: Davide Italiano > >> Cc: LLDB > >>

Re: [lldb-dev] [RFC]The future of pexpect

On Mon, Feb 25, 2019 at 1:35 PM Adrian Prantl wrote: > > > > > On Feb 25, 2019, at 1:15 PM, Davide Italiano wrote: > > > > On Fri, Feb 22, 2019 at 6:32 AM Pavel Labath wrote: > >> > >> On 21/02/2019 19:48, Ted Woodward wrote: > >>> > >>> > -Original Message- > From: lldb-dev

Re: [lldb-dev] [RFC]The future of pexpect

On Mon, Feb 25, 2019 at 1:57 PM Adrian Prantl wrote: > > > > > On Feb 25, 2019, at 1:40 PM, Davide Italiano wrote: > > > > On Mon, Feb 25, 2019 at 1:35 PM Adrian Prantl wrote: > >> > >> > >> > >>> On Feb 25, 2019, at 1:15 PM, Davide Italiano > >>> wrote: > >>> > >>> On Fri, Feb 22, 2019 at

Re: [lldb-dev] RFC: Moving debug info parsing out of process

On Sat, Mar 2, 2019 at 2:56 PM Adrian Prantl via lldb-dev wrote: > > > > On Feb 25, 2019, at 10:21 AM, Zachary Turner via lldb-dev > wrote: > > Hi all, > > We've got some internal efforts in progress, and one of those would benefit > from debug info parsing being out of process (independently

Re: [lldb-dev] Build failure on Linux

I think this might have been fixed, try to pull. On Tue, Mar 5, 2019 at 3:10 AM Gábor Márton via lldb-dev wrote: > > Hi, > > On trunk I receive the following build error on Linux: > ../../git/llvm/tools/lldb/include/lldb/lldb-forward.h:181:7: note: > forward declaration of

Re: [lldb-dev] [RFC]The future of pexpect

On Thu, Jan 31, 2019 at 11:40 AM Pavel Labath wrote: > > On 31/01/2019 19:51, Zachary Turner wrote: > > FileCheck the ansi escape codes seems like one possibility. > > > > In general I think you don't actually need to test true interactivity, > > because the odds of there being a problem in

Re: [lldb-dev] Flaky test on GreenDragon?

On Thu, Mar 7, 2019 at 7:04 AM Gábor Márton via lldb-dev wrote: > > Hi guys, > > I've seen that recently the test > lldb-Suite.macosx/queues.TestQueues.py fails non-deterministically. > > E.g. > http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/21271/testReport/ >

Re: [lldb-dev] [RFC]The future of pexpect

After discussing this privately with Pavel we decided to try updating pexpect instead. On Tue, Feb 26, 2019 at 4:42 AM Pavel Labath wrote: > > On 25/02/2019 22:15, Davide Italiano wrote: > > On Fri, Feb 22, 2019 at 6:32 AM Pavel Labath wrote: > >> > >> On 21/02/2019 19:48, Ted Woodward wrote: >

Re: [lldb-dev] RFC: Eliminate LLDB_DISABLE_PYTHON

I'm in favor of this. FWIW, I will be surprised if lldb works at all with that option. On Thu, Mar 7, 2019 at 10:28 AM Adrian McCarthy via lldb-dev wrote: > > We have a build option to build LLDB without Python. This option is > automatically set if Cmake can't find or "validate" your Python

Re: [lldb-dev] [RFC]The future of pexpect

On Thu, Jan 31, 2019 at 10:09 AM Pavel Labath wrote: > > On 31/01/2019 02:32, Davide Italiano via lldb-dev wrote: > > As you probably know (I didn’t), lldb embeds its own version of > > `pexpect-2.4`, which doesn’t support python3. > > This is the (relatively shor

[lldb-dev] [RFC]The future of pexpect

As you probably know (I didn’t), lldb embeds its own version of `pexpect-2.4`, which doesn’t support python3. This is the (relatively short) list of tests relying on pyexpect: testcases/tools/lldb-mi/syntax/TestMiSyntax.py:import pexpect # 7 (EOF)

Re: [lldb-dev] Trouble running Python tests on Windows

+ Stella/Pavel On Fri, May 31, 2019 at 8:42 AM Alexandre Ganea via lldb-dev wrote: > > Hi, > > > > I can’t seem to run the lldb python tests on my Windows 10 setup. I use the > following cmd-line to generate: > > > > cmake -G Ninja f:/svn/llvm -DCMAKE_BUILD_TYPE=Release >

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

On Thu, Jul 4, 2019 at 12:58 AM Zdenek Prikryl via lldb-dev < lldb-dev@lists.llvm.org> wrote: > We're using it with Eclipse and Eclipse based product, so I'd like to keep > as well! :-)... > > Zdenek > I do understand that there's desire from people to keep this around (from an user

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

On Mon, Jul 1, 2019 at 3:21 PM Ted Woodward via lldb-dev < lldb-dev@lists.llvm.org> wrote: > We’re using lldb-mi to debug with Eclipse in the Hexagon SDK. I’d really > like to keep it!  > > > Is there any reason why this can't be a downstream project? Thanks, -- Davide

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

On Wed, Aug 14, 2019 at 11:27 AM Adrian McCarthy via lldb-dev wrote: > > A recent change is causing several LLDB tests on Windows to fail and several > more to time out, which I intend to look into. > > It appears the timeout period is set to 600 seconds (10 minutes), which seems > excessive

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

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 testing LLDB commands it’s not obvious where to put files as > we test some commands directly in the top-level

Re: [lldb-dev] https://reviews.llvm.org/D69273

Thanks for the explanation. + Pavel & Adrian. On Thu, Oct 31, 2019 at 12:51 PM Jim Ingham via lldb-dev wrote: > > It looks like this change is causing problems with swift. I was talking a > little bit with Davide about this and it seems like it wasn't obvious how > this was designed to work.

Re: [lldb-dev] https://reviews.llvm.org/D69273

On Thu, Oct 31, 2019 at 1:06 PM Pavel Labath via lldb-dev wrote: > > (Just writing to say that tomorrow is a public holiday in most of > Europe, so I wont be able to meaningfully reply to this until > monday/tuesday. But if, in the mean time, you want to revert this, or > just limit the scope of

Re: [lldb-dev] Making LLVM_DEFAULT_TARGET_TRIPLE available to lldb's cmakery

On Wed, Oct 30, 2019 at 11:52 AM Jim Ingham via lldb-dev wrote: > > Except of course without the comment markers... > > > On Oct 30, 2019, at 11:36 AM, Jim Ingham wrote: > > > > Anyway, another way to do this would be something like: > > > > #if (${LLVM_DEFAULT_TARGET_TRIPLE}) > > string(REGEX

Re: [lldb-dev] Offline build bots

Presumably Pavel and Michal (both cc'ed). On Fri, Oct 11, 2019 at 3:06 PM António Afonso via lldb-dev wrote: > > Hi, > > All the *nix build bots (lldb-x86_86-{debian,fedora}, netbsd-amd64) have been > offline for a while now. Some as far as July 12. > I’m not sure if this is being tracked or

[lldb-dev] Saving and restoring STDIN in the ScriptInterpreter

Hi Pavel, Jonas, I was trying to reduce a bug through c-reduce, so I decided to write a SBAPI script to make it easier. I did find out, that after the first iteration, the reduction gets stuck forever. I sampled the process and I saw the following (trimmed for readability). Call graph: […]