Re: [lldb-dev] [llvm-dev] RFC: New Automated Release Workflow (using Issues and Pull Requests)

On Fri, Dec 17, 2021 at 6:38 PM Tom Stellard wrote: > On 12/17/21 16:47, David Blaikie wrote: > > Sounds pretty good to me - wouldn't mind knowing more about/a good > summary of the effects of this on project/repo/etc notifications that > Mehdi's mentioning. (be good to have a write up of the

Re: [lldb-dev] [llvm-dev] RFC: New Automated Release Workflow (using Issues and Pull Requests)

Sounds pretty good to me - wouldn't mind knowing more about/a good summary of the effects of this on project/repo/etc notifications that Mehdi's mentioning. (be good to have a write up of the expected impact/options to then discuss - from the thread so far I understand some general/high level

Re: [lldb-dev] Some API test failures are really opaque/could be improved

I haven't made any further progress on it - I think the actual git diff I posted, changing config.llvm_libs_dir wouldn't quite be shippable as-is, because it's only correct to add the "/@LLVM_DEFAULT_TARGET_TRIPLE@" if the runtimes were built with LLVM_ENABLE_PER_TARGET_RUNTIME_DIR ON (which is

Re: [lldb-dev] Some API test failures are really opaque/could be improved

On Mon, Oct 25, 2021 at 1:28 PM Louis Dionne wrote: > I believe the issue is probably not related so much to > LLVM_ENABLE_PROJECTS vs LLVM_ENABLE_RUNTIMES, but rather to the fact that > LLVM_ENABLE_RUNTIMES uses per-target runtime directories now (hasn't always > been the case), which basically

Re: [lldb-dev] Some API test failures are really opaque/could be improved

+Louis Dionne - perhaps the libcxx and lldb folks would be interesting in finding a suitable way to address this issue, since currently either option (using libcxx in ENABLE_PROJECTS or using it in ENABLE_RUNTIMES) is incomplete - if I use ENABLE_RUNTIMES I get the libcxx testing run against the

Re: [lldb-dev] [llvm-dev] Upstream an LLDB language plugin for D and support of custom expressions

+lldb-dev On Mon, Oct 25, 2021 at 9:36 AM Luís Ferreira via llvm-dev < llvm-...@lists.llvm.org> wrote: > Hi llvm-dev, > > I'm writing here to discuss the addition of D language plugin to LLDB. > Following the issue #52223 from Bugzilla, we are currently using C/C++ > language plugin for D. This

Re: [lldb-dev] Some API test failures are really opaque/could be improved

On Tue, Oct 19, 2021 at 4:55 PM David Blaikie wrote: > On Tue, Oct 19, 2021 at 9:08 AM Raphael Isemann > wrote: > >> Actually the RPATH theory is wrong, but the LLVM_ENABLE_PROJECT >> workaround *should* still work. >> > > I'll give that a go (it's running at the moment) though I guess this is

Re: [lldb-dev] Some API test failures are really opaque/could be improved

ccessfully. I'll either have to get used to ignoring certain failures, or > disable the tests by not building libcxx in that build tree, which would > also be unfortunate. (or maybe there's some other workarounds?) Any idea > how this works for other folks? > > > > > > - Dave > &g

Re: [lldb-dev] Some API test failures are really opaque/could be improved

ests by not building libcxx in that build tree, which would also be unfortunate. (or maybe there's some other workarounds?) Any idea how this works for other folks? - Dave - Raphael > > Am Mo., 18. Okt. 2021 um 05:54 Uhr schrieb David Blaikie via lldb-dev > : > > > >

[lldb-dev] libc++ pretty printer test dependencies

So I'm trying to run a clean "ninja check-lldb" and I'm running into some difficulties with the libc++ pretty printer tests. 1) They're "unsupported" if my host compiler is gcc: $ ninja check-lldb-api-functionalities-data-formatter-data-formatter-stl-libcxx [2/3] Running lit suite

[lldb-dev] Some API test failures are really opaque/could be improved

Wondering if anyone else has encountered/dealt with debugging lldb test failures like the one shown at the end of this email ("AssertionError: 10 != 5" in "test.assertEqual(process.GetState(), lldb.eStateStopped)" while checking that a breakpoint was reached) Is there anything that could be done

Re: [lldb-dev] [cfe-dev] [llvm-dev] RFC: Code Review Process

On Thu, Oct 7, 2021 at 3:44 PM Renato Golin wrote: > On Thu, 7 Oct 2021 at 23:16, David Blaikie wrote: > >> I don't think diversity necessarily relates to this aspect of managerial >> structure. Unless we're talking about the less benevolent dictatorships >> where the authority figures both

Re: [lldb-dev] [cfe-dev] [llvm-dev] RFC: Code Review Process

On Thu, Oct 7, 2021 at 3:02 PM Renato Golin wrote: > On Thu, 7 Oct 2021 at 22:31, David Blaikie wrote: > >> This is how we've always done it so far and it has been working well. At >>> least most people I know think that this is better than most other >>> alternatives, including ad-hoc decision

Re: [lldb-dev] [cfe-dev] [llvm-dev] RFC: Code Review Process

On Thu, Oct 7, 2021 at 2:22 PM Renato Golin via cfe-dev < cfe-...@lists.llvm.org> wrote: > On Thu, 7 Oct 2021 at 21:48, Reid Kleckner wrote: > >> I want to take the other side here, and say that I appreciate that the >> board is trying to provide more structure for this decision making process.

Re: [lldb-dev] [cfe-dev] [llvm-dev] Mailing List Status Update

On Mon, Jun 21, 2021 at 12:53 PM Chris Lattner via cfe-dev < cfe-...@lists.llvm.org> wrote: > On Jun 9, 2021, at 10:50 AM, Philip Reames via llvm-dev < > llvm-...@lists.llvm.org> wrote: > > Specific to the dev lists, I'm very hesitant about moving from mailing > lists to discourse. Why? > >

Re: [lldb-dev] [llvm-dev] [cfe-dev] Mailing List Status Update

On Tue, Jun 15, 2021 at 9:50 AM Matt P. Dziubinski wrote: > On 6/15/2021 18:29, David Blaikie wrote: > > > > > > On Tue, Jun 15, 2021 at 7:40 AM Matt P. Dziubinski via llvm-dev > > mailto:llvm-...@lists.llvm.org>> wrote: > > > > On 6/15/2021 12:58, Aaron Ballman via llvm-dev wrote: > >

Re: [lldb-dev] [llvm-dev] [cfe-dev] Mailing List Status Update

On Tue, Jun 15, 2021 at 7:40 AM Matt P. Dziubinski via llvm-dev < llvm-...@lists.llvm.org> wrote: > On 6/15/2021 12:58, Aaron Ballman via llvm-dev wrote: > > On Mon, Jun 14, 2021 at 5:41 PM James Y Knight via cfe-dev > > wrote: > >> > >> On Thu, Jun 3, 2021 at 6:19 PM James Y Knight > wrote: >

Re: [lldb-dev] [cfe-dev] [RFC] Deprecate pre-commit email code reviews in favor of Phabricator

On Tue, May 18, 2021 at 6:50 AM Krzysztof Parzyszek wrote: > Post-commit reviews are conducted, in order of preference, on Phabricator, > > This still seems like a change in practice that I'm not in favor of, > personally - due to the current divergence between email and phab review > feedback.

Re: [lldb-dev] [cfe-dev] [RFC] Deprecate pre-commit email code reviews in favor of Phabricator

On Mon, May 17, 2021 at 11:12 AM Krzysztof Parzyszek via cfe-dev < cfe-...@lists.llvm.org> wrote: > This is a revision of the previous RFC[1]. This RFC limits the scope to > pre-commit reviews only. > > > > *Statement:* > > Our current code review policy states[2]: > > “Code reviews are

Re: [lldb-dev] lldb/test/API/commands/help/TestHelp.py not running just-built lldb

Jonas helped me out here (Thanks!) Seems I was setting LD_LIBRARY_PATH for, so far as I recall, good reasons (I have some things installed locally in $HOME/install and I thought somewhere in the mists of time the executables ($HOME/install/bin) didn't naturally find some shared libraries in

[lldb-dev] lldb/test/API/commands/help/TestHelp.py not running just-built lldb

On Linux (Ubuntu) + cmake + ninja, it seems this test isn't testing the checked-out lldb, but instead running the system (or user-dir, in my case) installed lldb (see examples at the end of this email) If I remove the user-dir installed lldb then the test fails differently - complaining that it

Re: [lldb-dev] lldb subprogram ranges support

Thanks Sri. I've sent out https://reviews.llvm.org/D94063 and https://reviews.llvm.org/D94064 for review, which include fixes for the lldb+ranges-on-subprograms issues I could find so far. On Wed, Dec 30, 2020 at 6:53 PM Sriraman Tallam wrote: > > > On Tue, Dec 29, 2020 at 4:44 PM Sriraman

Re: [lldb-dev] lldb subprogram ranges support

On Wed, Dec 23, 2020 at 7:02 PM Sriraman Tallam wrote: > > > On Wed, Dec 23, 2020 at 4:46 PM David Blaikie wrote: > >> Hey folks, >> >> So I've been doing some more testing/implementation work on various >> address pool reduction strategies previously discussed back in January ( >>

[lldb-dev] lldb subprogram ranges support

Hey folks, So I've been doing some more testing/implementation work on various address pool reduction strategies previously discussed back in January ( http://lists.llvm.org/pipermail/llvm-dev/2020-January/thread.html#138029 ). I've committed a -mllvm flag to allow experimenting with the first

Re: [lldb-dev] [llvm-dev] Renaming The Default Branch

Awesome - thanks for making the plan/getting this underway! On Fri, Nov 13, 2020 at 3:57 PM Mike Edwards via llvm-dev wrote: > > Hi Everyone, > Many tech communities, including GitHub and Git, have moved away from term > “master branch” and replaced it with “main branch” in an > effort to

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

On Mon, Aug 31, 2020 at 4:38 PM Petr Hosek wrote: > There are several options, I've looked at couple of them and the one I > like the most so far is https://github.com/yhirose/cpp-httplib for a few > reasons: > > * It's MIT licensed. > I hesitate to get into it on the list, not-a-lawyer, etc.

Re: [lldb-dev] [cfe-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED]

Generally sounds pretty good to me - only variation on the theme (& certainly imho dealer's choice at this point - if you/whoever ends up doing this doesn't like the sound of it, they shouldn't feel they have to do it this way) - maybe creating blank issues up to the current bugzilla PR number (&

Re: [lldb-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED]

All things being equal, I'd prefer Richard Smith's proposal that doesn't involve needing a new/old numbering scheme, but lets us keep a single numbering/redirection (& I doubt we need the first 200 bugs in any case - has anyone referred to bugs that early in the last 5 years, say? But wouldn't

Re: [lldb-dev] [llvm-dev] RFC: Using GitHub Actions for CI testing on the release/* branches

Not having given it deep thought/analysis, nor understanding much of the GIT infrastructure here, but: Sounds good to me, for whatever that's worth :) On Mon, Nov 11, 2019 at 4:32 PM Tom Stellard via llvm-dev < llvm-...@lists.llvm.org> wrote: > Hi, > > I would like to start using GitHub

Re: [lldb-dev] [llvm-dev] [cfe-dev] How soon after the GitHub migration should committing with git-llvm become optional?

I think it's a "Cross that bridge when we come to it" See if manual enforcement is sufficient - if it becomes a real problem that's too annoying to handle manually/culturally, then assess what sort of automation/enforcement seems appropriate for the situation we are in at that time. On Thu, Oct

Re: [lldb-dev] [llvm-dev] [cfe-dev] How soon after the GitHub migration should committing with git-llvm become optional?

On Thu, Oct 17, 2019 at 11:17 AM Philip Reames via llvm-dev < llvm-...@lists.llvm.org> wrote: > I'm also a strong proponent of not requiring the wrapper. > > The linear history piece was important enough to make the cost worth it. > The extra branches piece really isn't. If someone creates a

Re: [lldb-dev] [Openmp-dev] [cfe-dev] [llvm-dev] RFC: End-to-end testing

On Wed, Oct 16, 2019 at 6:05 PM David Greene wrote: > > I'm inclined to the direction suggested by others that the monorepo is > > orthogonal to this issue and top level tests might not be the right > thing. > > > > lldb already does end-to-end testing in its tests, for instance. > > > > Clang

Re: [lldb-dev] [cfe-dev] [Openmp-dev] [llvm-dev] RFC: End-to-end testing

On Wed, Oct 16, 2019 at 1:09 PM Roman Lebedev via cfe-dev < cfe-...@lists.llvm.org> wrote: > FWIW I'm personally cautiously non-optimistic about this, > but maybe i'm just not seeing the whole picture of the proposal. > > Both checking final asm, and checking more than one layer of abstraction >

Re: [lldb-dev] [cfe-dev] [Openmp-dev] [llvm-dev] RFC: End-to-end testing

On Wed, Oct 16, 2019 at 12:54 PM David Greene via cfe-dev < cfe-...@lists.llvm.org> wrote: > Renato Golin via Openmp-dev writes: > > > But if we have some consensus on doing a clean job, then I would > > actually like to have that kind of intermediary check (diagnostics, > > warnings, etc) on

Re: [lldb-dev] [llvm-dev] [cfe-dev] How soon after the GitHub migration should committing with git-llvm become optional?

On Tue, Oct 15, 2019 at 9:26 PM Mehdi AMINI via llvm-dev < llvm-...@lists.llvm.org> wrote: > > > On Tue, Oct 15, 2019 at 12:26 PM Hubert Tong via llvm-dev < > llvm-...@lists.llvm.org> wrote: > >> On Tue, Oct 15, 2019 at 3:47 AM Marcus Johnson via llvm-dev < >> llvm-...@lists.llvm.org> wrote: >>

Re: [lldb-dev] [Openmp-dev] [cfe-dev] RFC: End-to-end testing

On Tue, Oct 8, 2019 at 12:46 PM David Greene wrote: > David Blaikie via Openmp-dev writes: > > > I have a bit of concern about this sort of thing - worrying it'll lead to > > people being less cautious about writing the more isolated tests. > > That's a fair concern. Reviewers will still need

Re: [lldb-dev] [cfe-dev] RFC: End-to-end testing

I have a bit of concern about this sort of thing - worrying it'll lead to people being less cautious about writing the more isolated tests. That said, clearly there's value in end-to-end testing for all the reasons you've mentioned (& we do see these problems in practice - recently DWARF indexing

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

Yep, in theory maybe "partial units" could be used to address this - though any solution that's linker-agnostic will have some size overhead most likely (like type units) & I've never looked at them closely enough to know if just saying "partial units" is enough to describe the solution in detail

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

On Mon, Jun 18, 2018 at 9:54 AM wrote: > > Greg wrote: > > > Pavel wrote: > > > That said, having DWARF be able to represent the template member > > > functions in an abstract way also sounds like nice thing to have from > > > a debug info format. > > > > Yes, that would be great, but will

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

On Thu, Jun 14, 2018 at 11:24 AM Pavel Labath wrote: > On Thu, 14 Jun 2018 at 17:58, Greg Clayton wrote: > > > > > > > > On Jun 14, 2018, at 9:36 AM, Adrian Prantl wrote: > > > > > > > > On Jun 14, 2018, at 7:01 AM, Pavel Labath via llvm-dev < > llvm-...@lists.llvm.org> wrote: > > > > Thank

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

If you end up revisiting the design/representation here - I'd be glad to be involved. It reminds me of some of the tradeoffs/issues around how even plain C++ types vary between translation units (eg: member function template implicit specializations - necessarily different ones can appear in

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

Nice! Thanks for the update: re: ObjC: Perhaps debug_names and .apple_objc could be emitted at the same time to address that issue at least in the short term? As for size impact, have you tested this with fission and compressed debug info enabled? (both in terms of whether debug_names is as

Re: [lldb-dev] [llvm-dev] Running lit (googletest) tests remotely

On Wed, May 31, 2017 at 10:44 AM Matthias Braun via llvm-dev < llvm-...@lists.llvm.org> wrote: > > > On May 31, 2017, at 4:06 AM, Pavel Labath wrote: > > > > Thank you all for the pointers. I am going to look at these to see if > > there is anything that we could reuse, and

Re: [lldb-dev] [llvm-dev] DW_TAG_member extends beyond the bounds error on Linux

On Sat, Mar 26, 2016 at 11:31 PM, Jeffrey Tan wrote: > Thanks David. I meant to send to lldb maillist, but glad to hear response > here. > > Our binary is built from gcc: > String dump of section '.comment': > [ 1] GCC: (GNU) 4.9.x-google 20150123 (prerelease) > >

Re: [lldb-dev] [BUG] Many lookup failures

On Tue, Dec 1, 2015 at 11:29 AM, Greg Clayton wrote: > So one other issue with removing debug info from the current binary for > base classes that are virtual: if the definition for the base class changes > in libb.so, but liba.so was linked against an older version of class

Re: [lldb-dev] [BUG] Many lookup failures

On Mon, Nov 30, 2015 at 1:57 PM, Eric Christopher wrote: > > > On Mon, Nov 30, 2015 at 9:41 AM Greg Clayton via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >> So be sure to enable -fno-limit-debug-info to make sure the compiler >> isn't emitting lame debug info. >> >> >

Re: [lldb-dev] [BUG] Many lookup failures

On Mon, Nov 30, 2015 at 6:04 PM, Ramkumar Ramachandra wrote: > On Mon, Nov 30, 2015 at 5:42 PM, Greg Clayton wrote: > > When we debug "a.out" again, we might have recompiled "liba.so", but not > "libb.so" and when we debug again, we don't need to reload

Re: [lldb-dev] [BUG] Many lookup failures

On Mon, Nov 30, 2015 at 2:42 PM, Greg Clayton wrote: > > > > This will print out the complete class definition that we have for > "CG::Node" including ivars and methods. You should be able to see the > inheritance structure and you might need to also dump the type info for >

Re: [lldb-dev] [BUG] Many lookup failures

On Mon, Nov 30, 2015 at 3:29 PM, Greg Clayton wrote: > > > On Nov 30, 2015, at 2:54 PM, David Blaikie wrote: > > > > > > > > On Mon, Nov 30, 2015 at 2:42 PM, Greg Clayton > wrote: > > > > > > This will print out the complete class