[Lldb-commits] [lldb] [lldb][DWARFIndex] Use IDX_parent to implement GetFullyQualifiedType query (PR #79932)

@@ -218,6 +219,104 @@ void DebugNamesDWARFIndex::GetCompleteObjCClass( m_fallback.GetCompleteObjCClass(class_name, must_be_implementation, callback); } +namespace { +using Entry = llvm::DWARFDebugNames::Entry; + +/// If `entry` and all of its parents have an `IDX_parent`, u

[Lldb-commits] [lldb] [lldb][DWARFIndex] Use IDX_parent to implement GetFullyQualifiedType query (PR #79932)

@@ -0,0 +1,210 @@ +//===-- DWARFDIETest.cpp --=---===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: Ap

[Lldb-commits] [lldb] [lldb][DWARFIndex] Use IDX_parent to implement GetFullyQualifiedType query (PR #79932)

@@ -218,6 +219,104 @@ void DebugNamesDWARFIndex::GetCompleteObjCClass( m_fallback.GetCompleteObjCClass(class_name, must_be_implementation, callback); } +namespace { +using Entry = llvm::DWARFDebugNames::Entry; + +/// If `entry` and all of its parents have an `IDX_parent`, u

[Lldb-commits] [lldb] [lldb] Fix expressions that involve nested structs/classes/unions. (PR #77029)

dwblaikie wrote: How'd this work before your recent changes, then - when each repeated query would get one level further down in the nesting? How'd that work given the clang limitations you're describing? In any case, the extra clang requirements here seem like they might be of uncertain cost

[Lldb-commits] [lldb] [lldb] Fix a crash when using .dwp files and make type lookup reliable with the index cache (PR #79544)

dwblaikie wrote: > Even if we want to have the skeleton compile unit be parsed first, we would > need to know this from any accelerator table entry, wether it be from > .debug_names or from our internal manual index. True enough, but I think letting this become a lazy property post-constructi

[Lldb-commits] [lldb] [lldb] Fix a crash when using .dwp files and make type lookup reliable with the index cache (PR #79544)

dwblaikie wrote: > > > Even if we want to have the skeleton compile unit be parsed first, we > > > would need to know this from any accelerator table entry, wether it be > > > from .debug_names or from our internal manual index. > > > > > > True enough, but I think letting this become a lazy

[Lldb-commits] [lldb] f6b3875 - Reapply "lldb: Cache string hash during ConstString pool queries/insertions"

Author: David Blaikie Date: 2024-02-02T20:01:51Z New Revision: f6b387589d648945372528a4ac77c58f310e5165 URL: https://github.com/llvm/llvm-project/commit/f6b387589d648945372528a4ac77c58f310e5165 DIFF: https://github.com/llvm/llvm-project/commit/f6b387589d648945372528a4ac77c58f310e5165.diff LOG:

[Lldb-commits] [lldb] [lldb] Fix expressions that involve nested structs/classes/unions. (PR #77029)

dwblaikie wrote: Be great to see D101950 picked up again, so I'm glad to hear that's being looked at. Be nice to get some way to address this regression sooner rather than later... & yeah, I'd argue that classes derived from DWARF are not complete - nested types, member function templates, s

[Lldb-commits] [lldb] Add more ways to find the .dwp file. (PR #81067)

dwblaikie wrote: FWIW, I think we should be opinionated (& consistent with whatever gdb does, if it has some precedent here - if it is less opinionated, then maybe we have to be accepting) when it comes to whether x.debug goes with x.dwp or x.debug.dwp - we shouldn't support both unless there'

[Lldb-commits] [lldb] Add more ways to find the .dwp file. (PR #81067)

dwblaikie wrote: > If the DWO ID is just a hash of the file path or something that isn't > guaranteed to be unique with each new build, then we need the UUID in the > .dwp file. Nah, the DWO ID, as per spec, is a semantic hash of the DWARF contents. It should change, generally, if any part of

[Lldb-commits] [lldb] [lldb] Add more ways to find the .dwp file. (PR #81067)

dwblaikie wrote: > > FWIW, I think we should be opinionated (& consistent with whatever gdb > > does, if it has some precedent here - if it is less opinionated, then maybe > > we have to be accepting) when it comes to whether x.debug goes with x.dwp > > or x.debug.dwp - we shouldn't support bo

[Lldb-commits] [lldb] [lldb][DWARFIndex] Use IDX_parent to implement GetFullyQualifiedType query (PR #79932)

dwblaikie wrote: > I will aim to land this sometime tomorrow if there are no further objections Per the documentation ( https://llvm.org/docs/CodeReview.html#code-review-workflow ), please don't do this. Once it's sent for review, please wait for approval (ping as needed, etc) before landing.

[Lldb-commits] [lldb] [lldb] Add more ways to find the .dwp file. (PR #81067)

dwblaikie wrote: > I am fine with telling people what to do and giving them a golden path to > what is easiest for our debuggers. And I will suggest to everyone that they > use `.debug` and `.dwp`, but if we want to only support this, this leaves the > downloading of the `.debug` file requirin

[Lldb-commits] [lldb] [lldb][DWARFIndex] Use IDX_parent to implement GetFullyQualifiedType query (PR #79932)

dwblaikie wrote: > > > I will aim to land this sometime tomorrow if there are no further > > > objections > > > > > > Per the documentation ( > > https://llvm.org/docs/CodeReview.html#code-review-workflow ), please don't > > do this. Once it's sent for review, please wait for approval (ping

[Lldb-commits] [clang] [clang-tools-extra] [lldb] [c++20] P1907R1: Support for generalized non-type template arguments of scalar type. (PR #78041)

@@ -5401,6 +5409,8 @@ std::string CGDebugInfo::GetName(const Decl *D, bool Qualified) const { // feasible some day. return TA.getAsIntegral().getBitWidth() <= 64 && IsReconstitutableType(TA.getIntegralType()); + case Template

[Lldb-commits] [lldb] [lldb] Add more ways to find the .dwp file. (PR #81067)

dwblaikie wrote: > > > I am fine with telling people what to do and giving them a golden path to > > > what is easiest for our debuggers. And I will suggest to everyone that > > > they use `.debug` and `.dwp`, but if we want to only support this, this > > > leaves the downloading of the `.debu

[Lldb-commits] [lldb] [lldb] Add more ways to find the .dwp file. (PR #81067)

dwblaikie wrote: > > > If the client strips the debug info first into "a.out.debug" and then > > > runs llvm-dwp, they will end up with a "a.out.debug.dwp". We have clients > > > that are doing this already and we want to support them. > > > > > > OK, could we fix llvm-dwp to match the behavi

[Lldb-commits] [lldb] ed7be0d - lldb: Fix cross-cu-reference test to explicitly request that feature

Author: David Blaikie Date: 2023-06-01T00:35:39Z New Revision: ed7be0d4d17b5d1470587643cd5c55157414bb9c URL: https://github.com/llvm/llvm-project/commit/ed7be0d4d17b5d1470587643cd5c55157414bb9c DIFF: https://github.com/llvm/llvm-project/commit/ed7be0d4d17b5d1470587643cd5c55157414bb9c.diff LOG:

[Lldb-commits] [lldb] 40e971a - nullptr printing - update for a change to clang type printing that now uses "std::nullptr_t"

Author: David Blaikie Date: 2021-09-21T11:50:24-07:00 New Revision: 40e971a21052a8638933037615e3c681e193f3fc URL: https://github.com/llvm/llvm-project/commit/40e971a21052a8638933037615e3c681e193f3fc DIFF: https://github.com/llvm/llvm-project/commit/40e971a21052a8638933037615e3c681e193f3fc.diff

Re: [Lldb-commits] [lldb] 92b475f - [lldb] silence -Wsometimes-uninitialized warnings

Maybe this isn't the right fix - msbit and lsbit probably shouldn't be printed if to_integer returns false in the diagnostic on line 195. If that diagnostic didn't use the variables, then I don't think this'd warn? On Mon, Sep 27, 2021 at 12:38 AM Krasimir Georgiev via lldb-commits < lldb-commits@

[Lldb-commits] [lldb] f6a561c - DebugInfo: Use clang's preferred names for integer types

Author: David Blaikie Date: 2021-10-06T16:02:34-07:00 New Revision: f6a561c4d6754b13165a49990e8365d819f64c86 URL: https://github.com/llvm/llvm-project/commit/f6a561c4d6754b13165a49990e8365d819f64c86 DIFF: https://github.com/llvm/llvm-project/commit/f6a561c4d6754b13165a49990e8365d819f64c86.diff

[Lldb-commits] [lldb] d723ad5 - Enable libc++ in the build for libcxx initializerlist pretty printers

Author: David Blaikie Date: 2021-10-21T11:35:59-07:00 New Revision: d723ad5bcf7133c3f3950ebb63edf4ddfee56581 URL: https://github.com/llvm/llvm-project/commit/d723ad5bcf7133c3f3950ebb63edf4ddfee56581 DIFF: https://github.com/llvm/llvm-project/commit/d723ad5bcf7133c3f3950ebb63edf4ddfee56581.diff

[Lldb-commits] [lldb] 64f002c - Follow-up fixes for aee49255074fd4ef38d97e6e70cbfbf2f9fd0fa7

Author: David Blaikie Date: 2021-10-21T13:00:56-07:00 New Revision: 64f002c6d36d674a924c6116ec0b2d731cc3981c URL: https://github.com/llvm/llvm-project/commit/64f002c6d36d674a924c6116ec0b2d731cc3981c DIFF: https://github.com/llvm/llvm-project/commit/64f002c6d36d674a924c6116ec0b2d731cc3981c.diff

Re: [Lldb-commits] [lldb] 71cfce8 - [lldb] Fix TestCompressedVectors after array type name change

Thanks for the fix! (is there a buildbot email I should've got (or did and failed to understand) about this?) On Fri, Oct 22, 2021 at 1:16 AM Raphael Isemann via lldb-commits < lldb-commits@lists.llvm.org> wrote: > > Author: Raphael Isemann > Date: 2021-10-22T10:15:53+02:00 > New Revision: 71cfce

[Lldb-commits] [lldb] e6b3233 - Cleanup a few more PR36048 skips

Author: David Blaikie Date: 2021-10-29T14:10:42-07:00 New Revision: e6b323379e3195ba98bacc9216fe38025bda6104 URL: https://github.com/llvm/llvm-project/commit/e6b323379e3195ba98bacc9216fe38025bda6104 DIFF: https://github.com/llvm/llvm-project/commit/e6b323379e3195ba98bacc9216fe38025bda6104.diff

Re: [Lldb-commits] [lldb] 6438a52 - Revert "[clang] retain type sugar in auto / template argument deduction"

On Sun, Nov 14, 2021 at 3:30 PM Matheus Izvekov via lldb-commits < lldb-commits@lists.llvm.org> wrote: > > Author: Matheus Izvekov > Date: 2021-11-15T00:29:05+01:00 > New Revision: 6438a52df1c7f36952b6126ff7b978861b76ad45 > > URL: > https://github.com/llvm/llvm-project/commit/6438a52df1c7f36952b61

Re: [Lldb-commits] [lldb] 6438a52 - Revert "[clang] retain type sugar in auto / template argument deduction"

Thanks for the details! On Sun, Nov 14, 2021 at 3:39 PM Matheus Izvekov wrote: > Oops, my bad! > > The reason for reverting this is that this is a recent commit, and > there are reports of breakage building libANGLE which have not been > investigated. > > See https://reviews.llvm.org/D110216 for

[Lldb-commits] [lldb] [lldb][NFCI] Remove duplicated code in DWARFParser (PR #69531)

@@ -73,137 +69,18 @@ bool DWARFDebugInfoEntry::Extract(const DWARFDataExtractor &data, m_tag = abbrevDecl->getTag(); m_has_children = abbrevDecl->hasChildren(); // Skip all data in the .debug_info or .debug_types for the attributes - dw_form_t form; for (const auto &

[Lldb-commits] [lldb] [lldb][NFCI] Remove duplicated code in DWARFParser (PR #69531)

@@ -73,137 +69,18 @@ bool DWARFDebugInfoEntry::Extract(const DWARFDataExtractor &data, m_tag = abbrevDecl->getTag(); m_has_children = abbrevDecl->hasChildren(); // Skip all data in the .debug_info or .debug_types for the attributes - dw_form_t form; for (const auto &

[Lldb-commits] [lldb] [lldb][NFCI] Remove duplicated code in DWARFParser (PR #69531)

https://github.com/dwblaikie approved this pull request. https://github.com/llvm/llvm-project/pull/69531 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] Improve debug names index fetching global variables performance (PR #70231)

@@ -129,8 +129,19 @@ void DebugNamesDWARFIndex::GetGlobalVariables( DWARFUnit &cu, llvm::function_ref callback) { uint64_t cu_offset = cu.GetOffset(); bool found_entry_for_cu = false; - for (const DebugNames::NameIndex &ni: *m_debug_names_up) { -for (DebugNames::Na

[Lldb-commits] [lldb] Improve debug names index fetching global variables performance (PR #70231)

@@ -129,8 +129,19 @@ void DebugNamesDWARFIndex::GetGlobalVariables( DWARFUnit &cu, llvm::function_ref callback) { uint64_t cu_offset = cu.GetOffset(); bool found_entry_for_cu = false; - for (const DebugNames::NameIndex &ni: *m_debug_names_up) { -for (DebugNames::Na

[Lldb-commits] [lldb] [clang][DebugInfo] Emit global variable definitions for static data members with constant initializers (PR #70639)

@@ -0,0 +1,87 @@ +// RUN: %clangxx -target arm64-apple-macosx11.0.0 -g %s -emit-llvm -S -o - | FileCheck --check-prefixes=CHECK %s + +enum class Enum : int { + VAL = -1 +}; + +struct Empty {}; + +constexpr auto func() { return 25; } + +struct Foo { +static constexpr int cexp

[Lldb-commits] [lldb] [clang][DebugInfo] Emit global variable definitions for static data members with constant initializers (PR #70639)

dwblaikie wrote: > Should not we remove constant initializer from the type definition if we have > a DW_TAG_variable with a DW_AT_const_value now? Yep, +1 to this. This is where the type normalization benefit would come from - no longer having this const value on the member declaration, but on

[Lldb-commits] [lldb] [clang][DebugInfo] Emit global variable definitions for static data members with constant initializers (PR #70639)

dwblaikie wrote: > Summing the size of all *.o files in my local debug Clang build increased by > 0.7% with this patch That's a bit significant. Any chance you could get a per-section breakdown/growth on that? (& exact flags - is this with compressed debug info, for instance? Or not?) I use `

[Lldb-commits] [lldb] [clang][DebugInfo] Emit global variable definitions for static data members with constant initializers (PR #70639)

dwblaikie wrote: > > > Should not we remove constant initializer from the type definition if we > > > have a DW_TAG_variable with a DW_AT_const_value now? > > > > > > Yep, +1 to this. This is where the type normalization benefit would come > > from - no longer having this const value on the m

[Lldb-commits] [lldb] [clang] [clang][DebugInfo] Emit global variable definitions for static data members with constant initializers (PR #70639)

dwblaikie wrote: size report sounds generally OK - but there's a bunch of what look like unrelated or strange results in there, perhaps they weren't compared at exactly the same version? (like why did the apple_names size go down? How did the .text and .debuG_line size change at all? ) https:

[Lldb-commits] [clang] [lldb] [clang][DebugInfo] Emit global variable definitions for static data members with constant initializers (PR #70639)

@@ -67,15 +67,15 @@ int C::a = 4; // CHECK-NOT:size: // CHECK-NOT:align: // CHECK-NOT:offset: -// CHECK-SAME: flags: DIFlagStaticMember, -// CHECK-SAME: extraData: i1 true) +// CHECK-SAME: flags: DIFlagStaticMemb

[Lldb-commits] [clang] [lldb] [clang][DebugInfo] Emit global variable definitions for static data members with constant initializers (PR #70639)

@@ -5883,6 +5907,18 @@ void CGDebugInfo::finalize() { DBuilder.replaceTemporary(std::move(FwdDecl), cast(Repl)); } + for (auto const *VD : StaticDataMemberDefinitionsToEmit) { +assert(VD->isStaticDataMember()); + +if (auto It = DeclCache.find(VD); It != DeclCach

[Lldb-commits] [clang] [lldb] [clang][DebugInfo] Emit global variable definitions for static data members with constant initializers (PR #70639)

@@ -0,0 +1,87 @@ +// RUN: %clangxx -target arm64-apple-macosx11.0.0 -g %s -emit-llvm -S -o - | FileCheck --check-prefixes=CHECK %s + +enum class Enum : int { + VAL = -1 +}; + +struct Empty {}; + +constexpr auto func() { return 25; } + +struct Foo { +static constexpr int cexp

[Lldb-commits] [clang] [lldb] [clang][DebugInfo] Emit global variable definitions for static data members with constant initializers (PR #70639)

https://github.com/dwblaikie approved this pull request. Few minor issues, but looks good to me. (you metnioned somewhere an lldb issue I think with this patch when the value is removed from the static member declaration inside the class? If that's a problem - probably hold off on committing th

[Lldb-commits] [lldb] [clang] [clang][DebugInfo] Emit global variable definitions for static data members with constant initializers (PR #70639)

dwblaikie wrote: > That's true, if defined in a header, we'll emit a DW_TAG_variable for the > constant in each compile unit the header is included in. GCC does do the > right thing and only emit the definition DIE in a single CU. We should > probably do the same. Though not sure at which leve

[Lldb-commits] [clang] [lldb] [clang][DebugInfo] Emit global variable definitions for static data members with constant initializers (PR #70639)

dwblaikie wrote: > 2) always put DW_AT_const_value in DW_TAG_member. My understanding is that this is not possible. Dependent initializer expressions can't be evaluated in all cases - we're only allowed to evaluate them in the places the language allows us to, otherwise we might produce the w

[Lldb-commits] [lldb] [llvm] Emit DIE's size in bits when size is not a multiple of 8 (PR #69741)

dwblaikie wrote: > @dwblaikie I talked with Adrian, his idea is to emit the size in bits > whenever it does not cleanly fit in a byte. His point (and I agree) is that > there may be tools that can use this bit size, and if we always round up when > emitting the DWARF we will lose this informat

[Lldb-commits] [lldb] [llvm] Emit DIE's size in bits when size is not a multiple of 8 (PR #69741)

dwblaikie wrote: > > I guess one question that might be relevant - does Swift have something > > like sizeof and what result does it give for these sort of types with bits > > to spare? > > You can't actually use that with these types as these are special compiler > builtin types which aren't

[Lldb-commits] [lldb] [llvm] Emit DIE's size in bits when size is not a multiple of 8 (PR #69741)

dwblaikie wrote: > > I'm arguing it doesn't fit it particularly well. We use it for bit fields - > > which are pretty special, for instance, but it seems like this thing isn't > > quite like that - it does have a whole byte size (if you allocated an array > > of them, for instance, I'm guessin

[Lldb-commits] [lldb] 40501f1 - buildbot-based-debugging a Microsoft lldb test XPASS

Author: David Blaikie Date: 2022-10-04T21:38:33Z New Revision: 40501f1b4139e472094ac0d4102923d2730515a1 URL: https://github.com/llvm/llvm-project/commit/40501f1b4139e472094ac0d4102923d2730515a1 DIFF: https://github.com/llvm/llvm-project/commit/40501f1b4139e472094ac0d4102923d2730515a1.diff LOG:

Re: [Lldb-commits] [lldb] a3a9528 - [lldb] X-FAIL TestCPPStaticMembers on Windows

Might be worth a bug report and CC'ing some Windows-LLDB type folks on that for notice. On Tue, May 25, 2021 at 4:11 AM Raphael Isemann via lldb-commits < lldb-commits@lists.llvm.org> wrote: > > Author: Raphael Isemann > Date: 2021-05-25T13:10:19+02:00 > New Revision: a3a95286a73fddc4027de930fac2

[Lldb-commits] [lldb] c5d56fe - NFC: .clang-tidy: Inherit configs from parents to improve maintainability

Author: David Blaikie Date: 2021-06-08T08:25:59-07:00 New Revision: c5d56fec502f36a0c994835ca23bc93a6c682d95 URL: https://github.com/llvm/llvm-project/commit/c5d56fec502f36a0c994835ca23bc93a6c682d95 DIFF: https://github.com/llvm/llvm-project/commit/c5d56fec502f36a0c994835ca23bc93a6c682d95.diff

[Lldb-commits] [lldb] 1def257 - PR51018: Remove explicit conversions from SmallString to StringRef to future-proof against C++23

Author: David Blaikie Date: 2021-07-08T13:37:57-07:00 New Revision: 1def2579e10dd84405465f403e8c31acebff0c97 URL: https://github.com/llvm/llvm-project/commit/1def2579e10dd84405465f403e8c31acebff0c97 DIFF: https://github.com/llvm/llvm-project/commit/1def2579e10dd84405465f403e8c31acebff0c97.diff

[Lldb-commits] [lldb] 3784fc4 - Remove set-but-unused variable

Author: David Blaikie Date: 2021-08-26T16:58:47-07:00 New Revision: 3784fc493eb254bbed422f0bc83f01bee94a8195 URL: https://github.com/llvm/llvm-project/commit/3784fc493eb254bbed422f0bc83f01bee94a8195 DIFF: https://github.com/llvm/llvm-project/commit/3784fc493eb254bbed422f0bc83f01bee94a8195.diff

Re: [Lldb-commits] [lldb] 54d03a4 - [lldb/Interpreter][NFC] Replace default constructors/destructors bodies with "=default"

Any chance of removing some of these entirely, when they're the default (like the first class in this patch, `CommandHistory` - a default ctor (assuming it has no other ctors) and dtor are implicit, and don't need to be written out)? On Sun, Feb 28, 2021 at 8:24 AM Tatyana Krasnukha via lldb-commi

Re: [Lldb-commits] [lldb] 8cdcd41 - [lldb/Interpreter][NFC] Remove explicit default initialization of members and base classes

Nice cleanup! On Sun, Feb 28, 2021 at 8:24 AM Tatyana Krasnukha via lldb-commits < lldb-commits@lists.llvm.org> wrote: > > Author: Tatyana Krasnukha > Date: 2021-02-28T19:23:18+03:00 > New Revision: 8cdcd41e384b4901cd796f7be58c461647e54d18 > > URL: > https://github.com/llvm/llvm-project/commit/8c

[Lldb-commits] [lldb] e913a75 - Fix a warning about named return value not being moved-from.

Author: David Blaikie Date: 2021-03-01T09:25:26-08:00 New Revision: e913a754143f227b4aea5f695a2dcd2349101886 URL: https://github.com/llvm/llvm-project/commit/e913a754143f227b4aea5f695a2dcd2349101886 DIFF: https://github.com/llvm/llvm-project/commit/e913a754143f227b4aea5f695a2dcd2349101886.diff

[Lldb-commits] [lldb] 776be16 - Fix virtual-dtor warning a different way, since a virtual dtor is not required for this use case.

Author: David Blaikie Date: 2021-03-01T09:25:26-08:00 New Revision: 776be16ba0532dbb3d66cc104d15a7f13a154e3f URL: https://github.com/llvm/llvm-project/commit/776be16ba0532dbb3d66cc104d15a7f13a154e3f DIFF: https://github.com/llvm/llvm-project/commit/776be16ba0532dbb3d66cc104d15a7f13a154e3f.diff

Re: [Lldb-commits] [lldb] e76b866 - Revert "[lldb] Make the API, Shell and Unit tests independent lit test suites"

Would be great if you could include some detail in the commit message (or, in this case, in a follow-up reply) about why the patch was reverted, thanks! On Fri, Mar 19, 2021 at 5:57 PM Jonas Devlieghere via lldb-commits < lldb-commits@lists.llvm.org> wrote: > > Author: Jonas Devlieghere > Date: 2

Re: [Lldb-commits] [lldb] 3dc24bc - [LLDB] Re-land: Use path relative to binary for finding .dwo files.

For future reference it'd be good to include some details in a recommit including the original commit hash, the revert hash, the reason for the revert and what's changed in this commit to address that problem. For others reading along, according to the phab review this test hit a bug in lldb and t

[Lldb-commits] [lldb] 6dc2a6a - Remove some unnecessary explicit defaulted copy ctors to cleanup -Wdeprecated-copy

Author: David Blaikie Date: 2021-05-10T14:31:11-07:00 New Revision: 6dc2a6a8c9a0e4f8b46a0ba05430b77229789b8e URL: https://github.com/llvm/llvm-project/commit/6dc2a6a8c9a0e4f8b46a0ba05430b77229789b8e DIFF: https://github.com/llvm/llvm-project/commit/6dc2a6a8c9a0e4f8b46a0ba05430b77229789b8e.diff

[Lldb-commits] [lldb] fdb45f5 - lldb fix for b198de67e0bab462217db50814b1434796fa7caf (PCH/modular codegen refactor)

Author: David Blaikie Date: 2020-07-22T13:12:00-07:00 New Revision: fdb45f54b6c0de00ba3bfa5dd157161ebb12799d URL: https://github.com/llvm/llvm-project/commit/fdb45f54b6c0de00ba3bfa5dd157161ebb12799d DIFF: https://github.com/llvm/llvm-project/commit/fdb45f54b6c0de00ba3bfa5dd157161ebb12799d.diff

[Lldb-commits] [lldb] f7a49d2 - [WIP][DebugInfo] Lazily parse debug_loclist offsets

Author: David Blaikie Date: 2020-08-18T10:49:39-07:00 New Revision: f7a49d2aa691266497c4baa35f29ba0167b39d23 URL: https://github.com/llvm/llvm-project/commit/f7a49d2aa691266497c4baa35f29ba0167b39d23 DIFF: https://github.com/llvm/llvm-project/commit/f7a49d2aa691266497c4baa35f29ba0167b39d23.diff

[Lldb-commits] [lldb] 8036cf7 - llvm-dwarfdump: Skip tombstoned address ranges

Author: David Blaikie Date: 2020-10-04T13:43:29-07:00 New Revision: 8036cf7f5402ea7fc8564a9a2beae512c324bf3d URL: https://github.com/llvm/llvm-project/commit/8036cf7f5402ea7fc8564a9a2beae512c324bf3d DIFF: https://github.com/llvm/llvm-project/commit/8036cf7f5402ea7fc8564a9a2beae512c324bf3d.diff

Re: [Lldb-commits] [PATCH] D62634: Improve DWARF parsing and accessing by 1% to 2%

On Tue, Jun 4, 2019 at 4:15 AM Pavel Labath via Phabricator < revi...@reviews.llvm.org> wrote: > labath added a comment. > > In D62634#1527575 , @dblaikie > wrote: > > > > 1. We need to figure out whether there's a bug in clang and fix it. + > @dblaikie for

[Lldb-commits] [lldb] 0b05732 - fix lldb for recent libDebugInfoDWARF API change

Author: David Blaikie Date: 2020-10-23T19:20:38-07:00 New Revision: 0b057320453b90bb409f55f74386b6841546d48a URL: https://github.com/llvm/llvm-project/commit/0b057320453b90bb409f55f74386b6841546d48a DIFF: https://github.com/llvm/llvm-project/commit/0b057320453b90bb409f55f74386b6841546d48a.diff

[Lldb-commits] [lldb] 274afac - lldb: Add support for DW_AT_ranges on DW_TAG_subprograms

Author: David Blaikie Date: 2021-01-07T14:28:03-08:00 New Revision: 274afac9a17f43e5396a0d6c7a0741702596a7bd URL: https://github.com/llvm/llvm-project/commit/274afac9a17f43e5396a0d6c7a0741702596a7bd DIFF: https://github.com/llvm/llvm-project/commit/274afac9a17f43e5396a0d6c7a0741702596a7bd.diff

Re: [Lldb-commits] [PATCH] D94063: lldb: Add support for DW_AT_ranges on DW_TAG_subprograms

On Thu, Jan 7, 2021 at 3:37 PM Jim Ingham via lldb-commits wrote: > > > > > On Jan 7, 2021, at 2:29 PM, David Blaikie via Phabricator via lldb-commits > > wrote: > > > > dblaikie added a comment. > > > > In D94063#2485271 , @labath wrote: > > > >> In D940

[Lldb-commits] [lldb] 696775d - Fix subprogram_ranges.test by explicitly using lld

Author: David Blaikie Date: 2021-01-07T19:53:17-08:00 New Revision: 696775d96ecd20aacb7935541995a5554bb32ba8 URL: https://github.com/llvm/llvm-project/commit/696775d96ecd20aacb7935541995a5554bb32ba8 DIFF: https://github.com/llvm/llvm-project/commit/696775d96ecd20aacb7935541995a5554bb32ba8.diff

[Lldb-commits] [lldb] 2ff36e7 - lldb subprogram_ranges.test - remove dependence on temp file name

Author: David Blaikie Date: 2021-01-07T20:04:22-08:00 New Revision: 2ff36e79291486b489ae26418daa1b123473b405 URL: https://github.com/llvm/llvm-project/commit/2ff36e79291486b489ae26418daa1b123473b405 DIFF: https://github.com/llvm/llvm-project/commit/2ff36e79291486b489ae26418daa1b123473b405.diff

Re: [Lldb-commits] [PATCH] D94063: lldb: Add support for DW_AT_ranges on DW_TAG_subprograms

Thanks for all the context - so sounds like mostly based on (3) the recommendation would be for this to be an API test (is there a way to test the line table directly? good place for reference on the SB API options - I looked at a few tests and they seemed quite different ( lldb/test/API/functional

Re: [Lldb-commits] [PATCH] D94063: lldb: Add support for DW_AT_ranges on DW_TAG_subprograms

Thanks for the pointers! So I tried writing an API-type test for this line table/breakpoint behavior (it doesn't seem like it's entirely/just the line table (for one thing, the DWARF change is purely in the subprogram DIE, not in the line table)) and I can't seem to figure it out. The attached pa

Re: [Lldb-commits] [PATCH] D94846: Allow breakpoints to be set on C++11 inline initializers

"But because their source lines are outside the function source range" Not sure I understand that - the DWARF doesn't describe a function source range, right? Only the line a function starts on. And a function can have code from source lines in many files/offsets that are unrelated to the function

Re: [Lldb-commits] [PATCH] D94846: Allow breakpoints to be set on C++11 inline initializers

On Fri, Jan 15, 2021 at 6:22 PM Jim Ingham wrote: > > If you set a breakpoint on source lines with no line table entries, lldb > slides the actual match forward to the nearest line table entry to the given > line number. That's necessary for instance because if you lay out your > function defi

Re: [Lldb-commits] [PATCH] D94063: lldb: Add support for DW_AT_ranges on DW_TAG_subprograms

On Thu, Jan 14, 2021 at 2:56 PM Jim Ingham wrote: > > How were you setting the breakpoint in the case where it was failing from the > command line? The breakpoint you are examining in the test in your patches > is a "source regular expression" breakpoint. That would be "break set -p". > If y

Re: [Lldb-commits] [PATCH] D94846: Allow breakpoints to be set on C++11 inline initializers

On Tue, Jan 19, 2021 at 10:17 AM Jim Ingham wrote: > > > > > On Jan 17, 2021, at 10:47 AM, David Blaikie wrote: > > > > On Fri, Jan 15, 2021 at 6:22 PM Jim Ingham wrote: > >> > >> If you set a breakpoint on source lines with no line table entries, lldb > >> slides the actual match forward to th

Re: [Lldb-commits] [PATCH] D94063: lldb: Add support for DW_AT_ranges on DW_TAG_subprograms

t catch new compiler > > debug output bugs as well. So unless you have a good reason to use a > > .s file, you shouldn't. > > On 11/01/2021 02:37, David Blaikie via lldb-commits wrote: > > Thanks for all the context - so sounds like mostly based on (3) the > > reco

Re: [Lldb-commits] [PATCH] D94846: Allow breakpoints to be set on C++11 inline initializers

On Tue, Jan 19, 2021 at 2:55 PM Jim Ingham wrote: > > > > > On Jan 19, 2021, at 11:40 AM, David Blaikie wrote: > > > > On Tue, Jan 19, 2021 at 10:17 AM Jim Ingham wrote: > >> > >> > >> > >>> On Jan 17, 2021, at 10:47 AM, David Blaikie wrote: > >>> > >>> On Fri, Jan 15, 2021 at 6:22 PM Jim Ingha

[Lldb-commits] [lldb] 78d41a1 - lldb: Add support for printing variables with DW_AT_ranges on DW_TAG_subprograms

Author: David Blaikie Date: 2021-01-24T18:39:06-08:00 New Revision: 78d41a1295d9d40c37758230d0218c61eaffad88 URL: https://github.com/llvm/llvm-project/commit/78d41a1295d9d40c37758230d0218c61eaffad88 DIFF: https://github.com/llvm/llvm-project/commit/78d41a1295d9d40c37758230d0218c61eaffad88.diff

Re: [Lldb-commits] [PATCH] D94063: lldb: Add support for DW_AT_ranges on DW_TAG_subprograms

On Fri, Jan 22, 2021 at 5:37 AM Pavel Labath wrote: > On 19/01/2021 23:23, David Blaikie wrote: > > On Tue, Jan 19, 2021 at 1:12 AM Pavel Labath wrote: > > Yeah - I have mixed feelings about debugger testing here - it is nice > > to have end-to-end tests which makes for handy debugger testing >

Re: [Lldb-commits] [PATCH] D94063: lldb: Add support for DW_AT_ranges on DW_TAG_subprograms

On Fri, Jan 22, 2021 at 9:42 AM Jim Ingham wrote: > If you are just loading an object file and the looking at the line table > or something like that, would a UnitTest be more suitable? > Maybe, though for what it's worth, this isn't an issue with the line table (well, not the .debug_line conten

Re: [Lldb-commits] [PATCH] D94063: lldb: Add support for DW_AT_ranges on DW_TAG_subprograms

On Mon, Jan 25, 2021 at 10:39 AM Jim Ingham wrote: > lldb creates a single line table out of the debug_line input and the > inlined_subroutine info from the debug_info. For instance, if you have a > nested set of inlines that all have the same start address, they cannot be > represented in the d

Re: [Lldb-commits] [lldb] 5a63045 - [LLDB] Fix `Wunused-result` warning

Might be worth making an "execution override" object that has a dtor to do the cleanup? On Mon, Feb 8, 2021 at 9:10 AM Frederik Gossen via lldb-commits wrote: > > > Author: Frederik Gossen > Date: 2021-02-08T18:10:08+01:00 > New Revision: 5a63045fe78834937785ed5081052e083a98077f > > URL: > https

[Lldb-commits] [lldb] 208a11a - Reapply "llvm-dwarfdump: Report errors when failing to parse loclist/debug_loc entries""

Author: David Blaikie Date: 2020-04-14T14:44:32-07:00 New Revision: 208a11ab3a7be7c3e5d3fae9dd4affdb01a0ed1f URL: https://github.com/llvm/llvm-project/commit/208a11ab3a7be7c3e5d3fae9dd4affdb01a0ed1f DIFF: https://github.com/llvm/llvm-project/commit/208a11ab3a7be7c3e5d3fae9dd4affdb01a0ed1f.diff

[Lldb-commits] [clang] [clang-tools-extra] [flang] [lld] [lldb] [llvm] [NFC] Rename Option parsing related files from OptXYZ -> OptionXYZ (PR #110692)

dwblaikie wrote: Yeah, I think given how wide the change is and the speculative nature of the harm - probably best to abandon this for now. We can pick it up again if more folks speak up/more evidence is presented that it's problematic. https://github.com/llvm/llvm-project/pull/110692

[Lldb-commits] [lldb] [llvm] [lldb-dap] Support column breakpoints (PR #113787)

@@ -78,7 +78,7 @@ class DWARFDebugLine { /// The maximum number of individual operations that may be encoded in an /// instruction. uint8_t MaxOpsPerInst; -/// The initial value of theis_stmtregister. +/// The initial value of the is_stmt register. -

[Lldb-commits] [lldb] [llvm] lldb simplified template names rebuild without clang ast (PR #90008)

dwblaikie wrote: > Very cool! Yeah, I had loftier goals of taking this even further (some of lldb's comparisons are DIE-to-DIE (eg: when trying to find a definition from a declaration) and in that case it'd be nice to not create any strings (when not using simplified template names, lldb sort

[Lldb-commits] [lldb] [llvm] [DebugInfo] Add explicit visibility macros to CodeView template functions (PR #113102)

dwblaikie wrote: @zmodem perhaps you know someone who might be able to look at a CodeView change? https://github.com/llvm/llvm-project/pull/113102 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo

[Lldb-commits] [lldb] [llvm] [DWARF] Fix DWARTTypePrinter unable to print qualified name for DW_TAG_typedef DIE (PR #117239)

dwblaikie wrote: > > Where those names go from "const string" to "const std::__1::string" (and > > from "string" to "std::__1::string")? or something like that. > > Yes. In some cases, it's getting super verbose, e.g: > `std::__1::basic_string, > std::__1::allocator >::value_type`. Oh yeah,

[Lldb-commits] [lldb] [llvm] [lldb][dwarf] Compute fully qualified names on simplified template names with DWARFTypePrinter (PR #117071)

dwblaikie wrote: if you're sending things for presubmit checks, but not for precommit review, please include the `skip-precommit-approval` label - but in this case it looks like you requested review, but then submitted without waiting for that review? Please don't do that, per: https://llvm.o

[Lldb-commits] [clang] [clang-tools-extra] [flang] [lldb] [llvm] [mlir] [polly] Add static to command line option (cl::opt) (PR #126243)

dwblaikie wrote: > I don't quite follow the motivation for this, can you expand on this in the > description please? Right now this seems unnecessary for the changes I can > see in MLIR for example. The linked bug seems to explain it, I think? It seems to be the usual "if something isn't/does

[Lldb-commits] [clang] [clang-tools-extra] [flang] [lldb] [llvm] [mlir] [polly] Add static to command line option (cl::opt) (PR #126243)

dwblaikie wrote: > > > I don't quite follow the motivation for this, can you expand on this in > > > the description please? Right now this seems unnecessary for the changes > > > I can see in MLIR for example. > > > > > > The linked bug seems to explain it, I think? It seems to be the usual

[Lldb-commits] [lldb] [llvm] [DWARF] Fix DWARTTypePrinter unable to print qualified name for DW_TAG_typedef DIE (PR #117239)

dwblaikie wrote: > Just noticed that this breaks > `llvm/test/tools/dsymutil/X86/DWARFLinkerParallel/odr-string.test` because > for `DW_TAG_typedef`, llvm-dwarfdump will print the fully qualified name > instead of the base name in DW_AT_type that refers to > it([here](https://github.com/llvm/

[Lldb-commits] [lldb] [llvm] [DWARF] Fix DWARTTypePrinter unable to print qualified name for DW_TAG_typedef DIE (PR #117239)

dwblaikie wrote: Rather than a unit test, perhaps this could be tested with llvm-dwarfdump? (I think that's how I tested the DWARFTypePrinter during its initial development) It's a feature improvement to llvm-dwarfdump - being able to print out names better. I guess most of what I did was mor

[Lldb-commits] [lldb] [llvm] [Support] [lldb] Fix thread jump #45326 (PR #135778)

dwblaikie wrote: Looks like this could/should be 2-3 comits. The ADT change is one, the llvm-symbolizer could be another (with or without the lldb test coverage), then possibly the lldb test coverage as a separate third step. (the contents of the patch I don't have much opinion on, I haven't e

[Lldb-commits] [lldb] [llvm] [NFC] Separate high-level-dependent portions of DWARFExpression (PR #139175)

dwblaikie wrote: @jmorse DWARF expressions might be your wheelhouse/you know someone who'd be up for reviewing this? https://github.com/llvm/llvm-project/pull/139175 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-

<    1   2