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

2017-08-14 Thread Adrian Prantl via lldb-dev
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

Re: [lldb-dev] LLDB tests

2017-07-31 Thread Adrian Prantl via lldb-dev
> 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

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

2017-05-03 Thread Adrian Prantl via lldb-dev
[+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

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

2017-11-28 Thread Adrian Prantl via lldb-dev
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

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

2018-04-27 Thread Adrian Prantl via lldb-dev
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

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

2018-06-14 Thread Adrian Prantl via lldb-dev
> 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

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

2018-06-26 Thread Adrian Prantl via lldb-dev
> 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

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

2018-06-26 Thread Adrian Prantl via lldb-dev
> 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 --

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

2018-01-17 Thread Adrian Prantl via lldb-dev
> 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 >

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

2018-01-18 Thread Adrian Prantl via lldb-dev
> 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

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

2018-01-17 Thread Adrian Prantl via lldb-dev
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.

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

2018-01-17 Thread Adrian Prantl via lldb-dev
> 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

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

2018-01-17 Thread Adrian Prantl via lldb-dev
> 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

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

2018-01-17 Thread Adrian Prantl via lldb-dev
> 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

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

2018-01-17 Thread Adrian Prantl via lldb-dev
> On Jan 17, 2018, at 1:13 PM, Davide Italiano <dccitali...@gmail.com> wrote: > > On Wed, Jan 17, 2018 at 1:02 PM, Davide Italiano <dccitali...@gmail.com> > wrote: >> On Wed, Jan 17, 2018 at 12:32 PM, Adrian Prantl via lldb-dev >> <lldb-dev@lists.llvm.org

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

2018-01-17 Thread Adrian Prantl via lldb-dev
Jan 17, 2018 at 1:02 PM, Davide Italiano <dccitali...@gmail.com> >> wrote: >>> On Wed, Jan 17, 2018 at 12:32 PM, Adrian Prantl via lldb-dev >>> <lldb-dev@lists.llvm.org> wrote: >>>> Hi lldb-dev! >>>> >>>> I've been investigating some s

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

2018-01-17 Thread Adrian Prantl via lldb-dev
> 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

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

2018-01-17 Thread Adrian Prantl via lldb-dev
> 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

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

2018-01-17 Thread Adrian Prantl via lldb-dev
> 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

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

2018-01-17 Thread Adrian Prantl via lldb-dev
> 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

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

2018-01-30 Thread Adrian Prantl via lldb-dev
> 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

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

2018-01-30 Thread Adrian Prantl via lldb-dev
> 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

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

2018-02-07 Thread Adrian Prantl via lldb-dev
> 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

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

2018-08-10 Thread Adrian Prantl via lldb-dev
> 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: > >

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

2018-08-10 Thread Adrian Prantl via lldb-dev
[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. >> > >

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

2018-08-10 Thread Adrian Prantl via lldb-dev
[+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

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

2018-08-10 Thread Adrian Prantl via lldb-dev
> 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

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

2018-08-10 Thread Adrian Prantl via lldb-dev
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

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

2018-08-10 Thread Adrian Prantl via lldb-dev
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 >

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

2018-08-13 Thread Adrian Prantl via lldb-dev
> 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) >

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

2018-08-13 Thread Adrian Prantl via lldb-dev
> 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

2018-08-15 Thread Adrian Prantl via lldb-dev
> 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

2018-08-13 Thread Adrian Prantl via lldb-dev
> 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

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

2018-08-14 Thread Adrian Prantl via lldb-dev
> 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) >

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

2018-08-14 Thread Adrian Prantl via lldb-dev
> 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 >

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

2018-08-14 Thread Adrian Prantl via lldb-dev
> 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

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

2018-08-24 Thread Adrian Prantl via lldb-dev
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]

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

2018-01-18 Thread Adrian Prantl via lldb-dev
> 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

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

2018-03-12 Thread Adrian Prantl via lldb-dev
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

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

2018-03-12 Thread Adrian Prantl via lldb-dev
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

[lldb-dev] Welcome Alexander!

2018-04-23 Thread Adrian Prantl via lldb-dev
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] DW_OP_deref handling

2018-10-12 Thread Adrian Prantl via lldb-dev
> 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 >

Re: [lldb-dev] DW_OP_deref handling

2018-10-12 Thread Adrian Prantl via lldb-dev
> 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] [llvm] r343874 - DwarfDebug: Pick next location in case of missing location at block begin

2018-10-11 Thread Adrian Prantl via lldb-dev
> 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

[lldb-dev] When should ArchSpecs match?

2018-12-06 Thread Adrian Prantl via lldb-dev
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. > { >

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

2019-01-07 Thread Adrian Prantl via lldb-dev
> 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

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

2019-01-03 Thread Adrian Prantl via lldb-dev
> 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 >>

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

2019-01-27 Thread Adrian Prantl via lldb-dev
> 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

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

2019-01-28 Thread Adrian Prantl via lldb-dev
> 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++ >>>

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

2019-02-25 Thread Adrian Prantl via lldb-dev
> 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

2019-02-25 Thread Adrian Prantl via lldb-dev
> 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

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

2019-02-25 Thread Adrian Prantl via lldb-dev
> 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,

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

2019-03-02 Thread Adrian Prantl via lldb-dev
> 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). > >

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

2019-03-06 Thread Adrian Prantl via lldb-dev
> 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

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

2019-03-08 Thread Adrian Prantl via lldb-dev
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

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

2019-02-13 Thread Adrian Prantl via lldb-dev
> 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

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

2019-01-29 Thread Adrian Prantl via lldb-dev
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

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

2019-01-30 Thread Adrian Prantl via lldb-dev
> 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

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

2019-03-11 Thread Adrian Prantl via lldb-dev
> 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

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

2019-03-11 Thread Adrian Prantl via lldb-dev
> 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