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

Forgive me if I'm wrong, but if the community consensus is that we should continue to use Phabricator, and Phabricator is not being provided/maintained by the LLVM Foundation, isn't it moot what the LLVM Foundation/Infrastructure Working Group recommends/wants to happen? The current maintainers wou

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

The github URL is not the "rG" one being referred to here. If you wanted to do a post-commit review on the commit, you'd go to https://reviews.llvm.org/rGb04148f77713c92ee57b33b7b858ad18ce8d78e3, which is a part of Phabricator. You can comment on this page, much in the same way as you would a D

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

Github may do things in a canonical way, but I think you'll find that lots of people will refer to them by other means in review comments, email threads, etc. Let's avoid any risk of ambiguity... Also, there's no guarantee in the future that Github won't decide to start auto-linking PR1234 as well

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

Similar to other people's experiences, I've worked on a common code base that supported three different platforms, and each platform used a different bugzilla with it's own numbering scheme. I regularly came across references to "BZ123456" with no indication as to which of the three systems that re

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

Please could we replace the "llvm-tools" with a single label for each LLVM tool (i.e. labels for llvm-ar, llvm-as, llvm-cxxfilt, llvm-objdump etc etc). As mentioned on multiple occasions now, this is much more user-friendly both for people filing issues, and for those like myself who are only inter

Re: [lldb-dev] [cfe-dev] [10.0.0 Release] Release Candidate 5 is here

Hi Hans, I don't know if you'll be planning on RC6, but this bug: https://bugs.llvm.org/show_bug.cgi?id=45271 was just filed as a regression in LLVM 10 versus LLVM 9, and looks like it could break things (potentially silently) for at least some installations of llvm-strip. There's a fix that's ba

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

Quite possibly. I am one of the current self-volunteered triagers on each of the GNU-equivalent LLVM binutils, and somebody who is therefore on the CC list for several bugzilla components with small numbers. I don't have the expertise to triage 95% of issues that come in elsewhere so me being in so

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

On Mon, 16 Mar 2020 at 15:08, Tom Stellard wrote: > On 03/16/2020 08:00 AM, James Henderson wrote: > > > > > > On Mon, 16 Mar 2020 at 14:44, Tom Stellard via cfe-dev < > cfe-...@lists.llvm.org > wrote: > > > > On 02/10/2020 07:40 PM, Tom Stellard wrote: > >

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

On Mon, 16 Mar 2020 at 14:44, Tom Stellard via cfe-dev < cfe-...@lists.llvm.org> wrote: > On 02/10/2020 07:40 PM, Tom Stellard wrote: > > On 01/30/2020 12:47 PM, David Major wrote: > >> Would it make sense to wait until 10.0.0 is released, in order to keep > all the blockers in one place? > >> > >

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

I'm happy to test things out, as long as it's not too much of a time sink (I have a lot on my plate at the moment, so something that takes more than the odd few minutes here and there may not be feasible). On Sat, 1 Feb 2020 at 02:10, Fangrui Song wrote: > On 2020-01-31, Tom Stellard via llvm-de

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

My only concern is the ability to get auto-subscribed onto issues for specific tools (i.e. the setup I currently have). If that can be resolved in a satisfactory manner, then I'm all for this (although less than two weeks seems like a rather ambitious time to switch over...). If it can't, then I'd

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

Although I've not had any Github Action experience, and despite being one who has raised objections to other parts of adopting github features, this sounds like a sensible idea. It seems odd to me that we don't already have some form of CI for our releases, so anything that improves on that is grea

Re: [lldb-dev] [llvm-dev] [cfe-dev] [Call for Volunteers] Bug triaging

TLDR; Please don't just straight-up remove components based on some arbitrary numeric threshold. Just because a component doesn't get many bugs filed against it doesn't mean it isn't useful. It might just mean that the area is generally pretty stable or simply new. A good example to work with are

Re: [lldb-dev] LLDB behaviour for GCed sections

r-section references and > relative offsets in DWARF. > > Not tried with llvm 4.0 or lld or gold. > > > David Earlam > Staff-Senior[Engineer]/Manager ? Software : Development Tools() { > Qualcomm Technologies International, Ltd. > . > > From: lldb-dev [mailto:lld

Re: [lldb-dev] LLDB behaviour for GCed sections

data when it garbage collects. > But I’ve not come across one that does this yet. I believe it is difficult > for linker implementors because of the inter-section references and > relative offsets in DWARF. > > Not tried with llvm 4.0 or lld or gold. > > > David Earl

[lldb-dev] LLDB behaviour for GCed sections

Hi, I’m currently investigating the behaviour of different debuggers when functions have been stripped by the linker because they are unused. I tried looking at the source code, but couldn’t really make enough sense of it to answer the question. Would someone be able to explain what LLDB’s behav