Re: [lldb-dev] Removing linux mips support

Sounds very reasonable to me. thanks for bringing this up! -- adrian > On Mar 9, 2021, at 12:24 AM, Pavel Labath via lldb-dev > wrote: > > Hi all, > > I propose to remove support for linux mips debugging. This basically amounts > to deleting > source/Plugins/Process/Linux/NativeRegisterCont

[lldb-dev] [Job Ad] Apple's debugging technologies team is hiring

The debugging technologies team at Apple is looking for engineers to work on LLDB and its testing and delivery. This is an opportunity to join a team that combines compiler technology and debuggers under one umbrella to build great tools. LLDB is a core part of Apple's developer tools, used inte

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

t; > > >> On Nov 21, 2019, at 3:04 PM, Jonas Devlieghere >> <mailto:jo...@devlieghere.com>> wrote: > >> > >> I see a bunch of eros here: > >> http://lists.llvm.org/pipermail/www-scripts/2019-November/thread.html > >> <http://lists.

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

Re: [lldb-dev] Is bitcast breaking lldb a bug?

Does this still reproduce with lldb compiled from the current state of the git repository (ToT)? How do you know that it is LLDB loosing the variable and not clang? Does clang produce a location for the variable when you look at the dwarfdump output? -- adrian > On Feb 26, 2020, at 3:31 AM, Le

Re: [lldb-dev] What are the 'rules' to play nice with lldb-9?

> On Feb 25, 2020, at 5:29 PM, Levo DeLellis via lldb-dev > wrote: > > I'm thoroughly confused so I may say incorrect thing. I don't expect any > replies to this entire post but bits would be helpful. I'll double check if > you need me to be specific since it's likely I remember or ran somet

Re: [lldb-dev] [llvm-dev] Have the debugger show an away with a dynamic size?

I added the VLA support to clang and lldb about a year ago, so you'll need fairly recent version of both for it to work. -- adrian > On Feb 17, 2020, at 12:25 PM, Levo DeLellis wrote: > > It looks like I wasn't careful and mixed version. I compiled with clang-9 but > used lldb-6. Surprisingly

Re: [lldb-dev] [llvm-dev] Have the debugger show an away with a dynamic size?

That is interesting. According to LLDB's test/lang/c/vla/* frame variable for a VLA is supposed to work. Frame variable is also supposed to hide the __vla_expr0 artificial helper variable. Is this an older LLDB from your system or an LLDB you built from source? If yes, would you mind filing a bu

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

Please note that when you are testing for a DWARF 5 feature specifically, you should think about using either Assembler or yaml2obj as input to lock down the binary encoding. If you do this, it would be best to not require a living process in your test, so the test can run even on platforms that

Re: [lldb-dev] Optional Dependencies in LLDB

> 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 > auto-detecting optional dependencies in LLDB. Unless explicitly > specified, optional dependencies like editline will be enabled w

[lldb-dev] LLDB Website is not being updated

Hello Tanya, it looks like the cron job that is supposed to be updating the LLDB website isn't running or is otherwise blocked at the moment. You can see on https://lldb.llvm.org that it says "Welcome to the LLDB version 8 documentation!". We also recently removed the "Why a New Debugger?" head

Re: [lldb-dev] Hiding trampoline functions from the backtrace, is it possible ?

I think the best mechanism for this would be to ensure that the trampolines are marked up as DW_AT_artificial and/or DW_AT_trampoline by the compiler. I'm pretty sure LLDB then already knows how to hide artificial frames (somebody else can probably provide pointers for how that works). -- adria

Re: [lldb-dev] lldb access in Emacs via realgud

> On Sep 12, 2019, at 4:45 PM, Rocky Bernstein wrote: > > > > On Thu, Sep 12, 2019 at 5:51 PM Adrian Prantl > wrote: > > > > On Sep 12, 2019, at 2:24 PM, Rocky Bernstein > > wrote: > > > > > > > > On Thu, Sep 12, 2019 at 3:37 PM Adri

Re: [lldb-dev] lldb access in Emacs via realgud

> On Sep 12, 2019, at 2:24 PM, Rocky Bernstein wrote: > > > > On Thu, Sep 12, 2019 at 3:37 PM Adrian Prantl wrote: >> >> > On Sep 11, 2019, at 1:08 AM, Rocky Bernstein via lldb-dev >> > wrote: >> > >> > >> > Hi - I just wanted to mention that if there are emacs users there is an >> > i

Re: [lldb-dev] lldb access in Emacs via realgud

> On Sep 11, 2019, at 1:08 AM, Rocky Bernstein via lldb-dev > wrote: > > > Hi - I just wanted to mention that if there are emacs users there is an > interface to lldb via realgud. See https://github.com/realgud/realgud-lldb > > A MELPA package and ELPA packageElpa package are available too

Re: [lldb-dev] [RFC] Fast Conditional Breakpoints (FCB)

> On Aug 15, 2019, at 2:03 PM, Ismail Bennani via lldb-dev > wrote: > > I built Clang (and LLVM) in Release Mode with Debug Info (-O2), > and got these results: > > | Dwarf Occurences |Occurences | > |--|-| > | DW\_OP\_deref|1,570

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

> On Aug 14, 2019, at 11:26 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 > excessi

Re: [lldb-dev] Status of DWARF64 in LLDB

> On Mar 11, 2019, at 3:46 PM, Zachary Turner wrote: > > Given that: > > 1) LLVM doesn't produce DWARF64 > 2) GCC has to be patched to produce DWARF64 > 3) LLDB's support is only partial but is untested and appears to be missing > major pieces in order for it to work > 4) It's of questionable

Re: [lldb-dev] Status of DWARF64 in LLDB

> On Mar 11, 2019, at 12:45 PM, Zachary Turner via lldb-dev > wrote: > > I want to ask what the status of DWARF64 in LLDB is. I can tell there's some > support for it by reading the code, but it seems to have zero test coverage > so it's not clear to me that anyone depends on it. For examp

Re: [lldb-dev] Host is now dependency free

That's great news! I'm looking forward to having more fine-grained LLDB C++ modules. -- adrian > On Mar 8, 2019, at 1:00 PM, Zachary Turner via lldb-dev > wrote: > > It's been a long time coming and a lot of work to get here, but Host is now > dependency free. While this may not be enforced

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

> On Mar 6, 2019, at 9:43 AM, Zachary Turner wrote: > > > On Mon, Mar 4, 2019 at 10:32 AM Zachary Turner > wrote: > On Sat, Mar 2, 2019 at 2:56 PM Adrian Prantl > wrote: >> It becomes testable as an independent component, because you can j

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

> 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 of whether or not > the rest of LLDB is out of process). > > There'

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

> On Feb 25, 2019, at 2:21 PM, Davide Italiano wrote: > > 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

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

> 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 6:32 AM Pavel Labath wrote: On 21/02/2019 19:48, Ted Woodward wrote:

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

> 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 On Behalf Of Pavel Labath via lldb-dev Sent: Thursday, February

Re: [lldb-dev] Missing module (debug symbols?) for Swift

> On Feb 3, 2019, at 6:48 PM, Tabor Kelly via lldb-dev > wrote: > > Hello, > > I am new to LLDB and don't quite understand the relationship between > llvm.org and Apple. However, I would like to fix a bug that is > preventing me from debugging some code that I compiled with Swift 4.2 > on Ubu

Re: [lldb-dev] [llvm-dev] [Github] RFC: linear history vs merge commits

> On Jan 29, 2019, at 4:55 PM, Jeremy Lakeman via llvm-dev > wrote: > > 5. When a new feature is broken up into a patch series, the series should be > rebased then immediately merged to help identify the individual patches in > the history graph. Typically the LLVM development model discour

Re: [lldb-dev] [llvm-dev] [Github] RFC: linear history vs merge commits

A linear history makes it much easier to git-bisect, since each commit can be rolled back individually. Easier cross-project bisection is one of the advantages of having the monorepo, and I wouldn't want to loose that. -- adrian ___ lldb-dev mailing li

Re: [lldb-dev] lldb print c++ variables from dylib loaded in Swift application

> On Jan 27, 2019, at 10:29 AM, David M. Lary wrote: > > On Sun, Jan 27, 2019 at 10:33 AM Adrian Prantl > wrote: >>> On Jan 26, 2019, at 6:41 PM, David M. Lary via lldb-dev >>> wrote: >>> >>> I'm writing a Swift application for MacOS that makes use of a C/C++ >>> d

Re: [lldb-dev] lldb print c++ variables from dylib loaded in Swift application

> On Jan 26, 2019, at 6:41 PM, David M. Lary via lldb-dev > wrote: > > I'm writing a Swift application for MacOS that makes use of a C/C++ > dylib from a third party to interact with a film scanner. The > application uses dlopen() & dlsym() to discover and call the C wrapper > function for th

Re: [lldb-dev] [llvm-dev] [lit] check-all hanging

> On Jan 7, 2019, at 8:28 AM, Joel E. Denny via lldb-dev > wrote: > > On Mon, Jan 7, 2019 at 11:15 AM Davide Italiano > wrote: > On Sat, Jan 5, 2019 at 9:48 AM Joel E. Denny via lldb-dev > mailto:lldb-dev@lists.llvm.org>> wrote: > > > > On Fri, Jan 4, 2019 at 11:

Re: [lldb-dev] [llvm-dev] [lit] check-all hanging

> On Jan 3, 2019, at 8:30 AM, Frédéric Riss wrote: > > -llvm-dev + lldb-dev for the lldv test failures. > >> On Jan 3, 2019, at 7:33 AM, Joel E. Denny > > wrote: > >> Expected Passes: 57489 >> Expected Failures : 276 >> Unsupported Tests : 1883 >> U

[lldb-dev] When should ArchSpecs match?

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 cases really don't behave like I would have expected them to. > { > ArchS

Re: [lldb-dev] DW_OP_deref handling

> On Oct 12, 2018, at 9:53 AM, Adrian Prantl via lldb-dev > wrote: > > > >> On Oct 11, 2018, at 11:16 AM, Greg Clayton via lldb-dev >> wrote: >> >> DWARF5 finally added the ability to track what each value means on the >> expression stac

Re: [lldb-dev] DW_OP_deref handling

> On Oct 11, 2018, at 11:16 AM, Greg Clayton via lldb-dev > wrote: > > DWARF5 finally added the ability to track what each value means on the > expression stack. Prior to DWARF 5, we had no idea what each entry on the > expression value stack was (file address, load address > (Value::eValue

Re: [lldb-dev] [llvm] r343874 - DwarfDebug: Pick next location in case of missing location at block begin

> On Oct 11, 2018, at 4:42 PM, Matthias Braun wrote: > > I reverted things in r344318 now. > >> On Oct 10, 2018, at 5:02 PM, Jim Ingham wrote: >> >> Thanks for looking into this! >> >> When I was first working on inlined stepping, I found a bunch of cases where >> the line table info and

[lldb-dev] Announcing some new bots on green-dragon

Some of you may have noticed that green dragon underwent some changes this last week. On http://green.lab.llvm.org/green/view/LLDB/ we now have the following configurations that are being tested: - http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/ [New configuration in zorg] Release+

Re: [lldb-dev] Failing LIT-based lldb-mi tests

> On Aug 15, 2018, at 10:31 AM, Александр Поляков > wrote: > > I built an lldb myself. As far as I remember, this error has been seen in > swift's CI on machines running Linux. Adrian, could you correct me if I'm > wrong? > Yes, we have seen these test fail regularly, but I don't have any

Re: [lldb-dev] Failing LIT-based lldb-mi tests

> On Aug 14, 2018, at 2:43 PM, Александр Поляков wrote: > > Here is what I got from gdb-remote packet log: > > (gdb) > lldb-mi < 1> send packet: + > lldb-mi history[1] tid=0x784a < 1> send packet: + > lldb-mi < 19> send packet: $QStartNoAckMode#b0 > lldb-mi

Re: [lldb-dev] Failing LIT-based lldb-mi tests

> On Aug 14, 2018, at 2:13 PM, Александр Поляков wrote: > > After long-long debugging I found out that lldb-mi can't successfully launch > a process since sometimes it isn't connected with something(I don't know what > is it). > I found out that it fails after `if (IsConnected())` from > `GD

Re: [lldb-dev] Failing LIT-based lldb-mi tests

> On Aug 14, 2018, at 12:11 PM, Александр Поляков > wrote: > > It seems that the real problem is that sometimes lldb-mi can't launch a > process: > > build/bin/lldb-mi --synchronous a.out < > llvm/tools/lldb/lit/tools/lldb-mi/exec/exec-step-instruction.test > (gdb) > -file-exec-and-symbols

Re: [lldb-dev] Failing LIT-based lldb-mi tests

> On Aug 13, 2018, at 4:19 PM, Александр Поляков wrote: > > Yes, I do, I'm able to pass any command to lldb-mi before the breakpoint is > hit. I guess that making exec-run to block the control until the process > stops might be the solution we are looking for. Right. I believe that it should

Re: [lldb-dev] Failing LIT-based lldb-mi tests

> On Aug 13, 2018, at 11:54 AM, Александр Поляков > wrote: > > Oops, I made a mistake, I typed break-insert main. Here is the right output: > > build/bin/lldb-mi a.out > (gdb) > -file-exec-and-symbols "a.out" > ^done > (gdb) > =library-loaded,id="/home/alexander/workspace/gsoc/a.out",target-

Re: [lldb-dev] Failing LIT-based lldb-mi tests

> On Aug 11, 2018, at 3:58 AM, Александр Поляков wrote: > > I reproduced the test you suggested and got following output: > > build/bin/lldb-mi --synchronous a.out < > llvm/tools/lldb/lit/tools/lldb-mi/exec/lldb-mi-fail.test > (gdb) > -file-exec-and-symbols "a.out" > ^done > (gdb) > ^done >

Re: [lldb-dev] Failing LIT-based lldb-mi tests

That't interesting. Where you able to simulate the error seen on the bots by inserting a sleep() unto the debugged program? -- adrian > On Aug 10, 2018, at 5:06 PM, Александр Поляков wrote: > > It seems that lldb-mi in such a situation just hangs: > > build/bin/lldb-mi --synchronous bash > (g

Re: [lldb-dev] Failing LIT-based lldb-mi tests

> On Aug 10, 2018, at 4:50 PM, Александр Поляков wrote: > > One important question: what do you mean talking about "block"? Does it mean > that SBTarget::Launch blocks the process and the user can't continue working > with this process until it stops? Pretty much. The same way as the interac

Re: [lldb-dev] Failing LIT-based lldb-mi tests

I was wondering how this worked in the regular SBAPI that we use for all the "normal" python-based LLDB tests. The implementation of SBProcess::Continue() for example calls Process::Resume() or Process::ResumeSynchronous() depending on whether synchronous mode is set or not. It's not immediately

Re: [lldb-dev] Failing LIT-based lldb-mi tests

[adding lldb-dev back to the conversation] > On Aug 10, 2018, at 2:37 PM, Adrian Prantl wrote: > > > >> On Aug 10, 2018, at 2:25 PM, Александр Поляков >> wrote: >> >> I didn't check this yet. lldb-mi already runs LIT test in the --synchronous >> mode and the tests keep failing. >> > > Ye

Re: [lldb-dev] Failing LIT-based lldb-mi tests

> On Aug 10, 2018, at 11:13 AM, Adrian Prantl via lldb-dev > wrote: > > [+lldb-dev, since this affects all bots equally] > > Alexander, it looks like there is a race condition in some of the LIT-based > lldb-mi tests. > > For example, exec-next.test: > >

[lldb-dev] Failing LIT-based lldb-mi tests

[+lldb-dev, since this affects all bots equally] Alexander, it looks like there is a race condition in some of the LIT-based lldb-mi tests. For example, exec-next.test: # Test lldb-mi -exec-next command. # Check that we have a valid target created via '%lldbmi %t'. # CHECK: ^done -bre

Re: [lldb-dev] [llvm-dev] RFC: libtrace

> On Jun 26, 2018, at 1:38 PM, Zachary Turner wrote: > >> On Tue, Jun 26, 2018 at 1:28 PM Adrian Prantl wrote: >> >>> > On Jun 26, 2018, at 11:58 AM, Zachary Turner via llvm-dev >>> > wrote: >>> > A good example of this would be LLDB’s DWARF parsing code, which is more >>> > featureful than

Re: [lldb-dev] [llvm-dev] RFC: libtrace

> On Jun 26, 2018, at 11:58 AM, Zachary Turner via llvm-dev > wrote: > > Hi all, > > We have been thinking internally about a lightweight llvm-based ptracer. To > address one question up front: the primary way in which this differs from > LLDB is that it targets a more narrow use case -- t

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

> 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 idea, I am afraid the situation is not as > simple as just flipping a switch. Jonas is currently working on adding

Re: [lldb-dev] [cfe-dev] [RFC] Improving import failure checking strategy inside ASTImporter

Adding lldb-dev to the thread, since LLDB is a primary user of ASTImporter. > On Apr 27, 2018, at 8:54 AM, Aleksei Sidorin via cfe-dev > wrote: > > Hello Gabor, > > Thank you for the reply! > > 26.04.2018 12:39, Gábor Márton пишет: >> Hi Aleksei, >> >> It is a great and welcoming initiative

[lldb-dev] Welcome Alexander!

Please join me in welcoming Alexander Polyakov, who will be working on cleaning up and completing LLDB's lldb-mi fronted as part of his Google Summer Of Code project: Reimplement lldb-mi on top of the LLDB public SB API https://summerofcode.withgoogle.com/projects/#5427847301169152 -- adrian __

Re: [lldb-dev] lldb compiled from source 5X slower than homebrew or default lldb

If this is a Mac I would recommend to build both lldbs in RelWithDebInfo mode and then run them through Instruments and compare the traces. I'd be very interested in learning what the cause for the slowdown is. -- adrian > On Mar 12, 2018, at 2:57 PM, Timothee Cour wrote: > > after further in

Re: [lldb-dev] lldb compiled from source 5X slower than homebrew or default lldb

Have you tried diff'ing your cmake invocation against the on used by homebrew? -- adrian > On Mar 9, 2018, at 12:59 AM, Timothee Cour via lldb-dev > wrote: > > while testing out https://github.com/llvm-mirror/lldb/pull/3 I noticed > that when I compiled lldb from source (even un-modified from

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

> On Feb 6, 2018, at 9:29 AM, Davide Italiano via lldb-dev > wrote: > > On Tue, Feb 6, 2018 at 8:18 AM, Pavel Labath wrote: >> 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 ll

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

> On Jan 30, 2018, at 7:49 AM, Pavel Labath wrote: > > 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_na

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

> 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 apple tables, the .debug_names hashes are computed from > case-folded names (to enable case-insensit

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

> 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 -C does what you think it does. "make -C foo" is > basically equivalent to "cd foo && make", whi

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

> 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 -C does what you think it does. "make -C foo" is > basically equivalent to "cd foo && make", whi

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

> On Jan 17, 2018, at 3:26 PM, Greg Clayton via lldb-dev > wrote: > > Everything sounds good on this thread. My two cents: > > We should add some post verification after each test that looks for file that > are left over after the "clean" phase. This can help us catch the tests that > aren'

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

> On Jan 17, 2018, at 3:25 PM, Zachary Turner wrote: > > I don't know what would be involved in getting the tests building out of tree > with Make. But I do know it would be simple with CMake. I'm sure it's > probably not terrible with Make either, I just don't know enough about it to > sa

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

> On Jan 17, 2018, at 3:05 PM, Zachary Turner wrote: > > Note that we're going off topic from the original goal, and I just want to > re-iterate that I fully support smaller, incremental changes. Indeed. So just to close the loop on this, it sounds like everybody is in agreement that runnin

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

> On Jan 17, 2018, at 2:56 PM, Jim Ingham wrote: > >> >> On Jan 17, 2018, at 2:55 PM, Adrian Prantl wrote: >> >> >> >>> On Jan 17, 2018, at 2:50 PM, Jim Ingham wrote: >>> >>> >>> On Jan 17, 2018, at 2:49 PM, Adrian Prantl wrote: Question: how would you feel about conve

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

> On Jan 17, 2018, at 2:50 PM, Jim Ingham wrote: > > > >> On Jan 17, 2018, at 2:49 PM, Adrian Prantl wrote: >> >> >> >>> On Jan 17, 2018, at 2:31 PM, Zachary Turner wrote: >>> >>> I don't think new test authors really need to add CMake any more so than >>> they currently need to unders

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

> On Jan 17, 2018, at 2:31 PM, Zachary Turner wrote: > > I don't think new test authors really need to add CMake any more so than they > currently need to understand Make. Which is to say, not very much. Most > Makefiles are currently 1-2 lines of code that simply does nothing other than >

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

chary's point of view that the tests should be build artifacts that should be kept after an incremental build? -- adrian > > >> On Jan 17, 2018, at 1:13 PM, Davide Italiano via lldb-dev >> wrote: >> >> On Wed, Jan 17, 2018 at 1:02 PM, Davide Italiano >

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

> On Jan 17, 2018, at 1:13 PM, Davide Italiano wrote: > > 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 investiga

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

> On Jan 17, 2018, at 12:41 PM, Zachary Turner wrote: > > If we're going to be making any significant changes to the way inferiors are > compiled, why not use cmake? Make clean is already not implemented correctly > in many places, leading to lots of remnants left over in the source tree >

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

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 directories and this prompted me to ask a couple of general noob questions about the LLDB testsuite. M

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

> On Jan 17, 2018, at 9:20 AM, Jonas Devlieghere via llvm-dev > wrote: > > 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) acceler

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

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 line tools without installing Xcode). When the command line tools are install

Re: [lldb-dev] [llvm-dev] Remotely launching a new process with LLDB

I would recommend asking this on the lldb mailing list instead. -- adrian > On Nov 26, 2017, at 8:30 AM, Lior Halphon via llvm-dev > wrote: > > I'm trying to remotely launch and debug a new process with lldb without much > success. > > Attaching to an already launched process works well by r

Re: [lldb-dev] [llvm-dev] Apple radar references in the LLDB test suite

This is a very reasonable request, but I think it is better directed at lldb-dev. -- adrian On Aug 14, 2017, at 8:27 AM, Ed Maste via llvm-dev wrote: > > > I was recently looking at an unexpected pass test result on FreeBSD[1] > which is decorated with expectedFailureAll referencing > rdar:/

Re: [lldb-dev] LLDB tests

> On Jul 24, 2017, at 10:48 AM, Sean Callanan via lldb-dev > wrote: > > Steve, > > since you asked about failures, here are some public bots you can look at to > get a general sense of how we are doing: > > http://lab.llvm.org:8011/builders > [various pla

Re: [lldb-dev] [llvm-dev] RFC: Improving the performance of ItaniumDemangle

[+lldb-dev] > On May 3, 2017, at 2:46 AM, Pavel Labath via llvm-dev > wrote: > > One of the things we need in lldb is to find a "basename" of a > function. This is so that you can set a breakpoint on a function named > "foo", even if "foo" is a method of a template class declared inside > anoth