[lldb-dev] [Bug 43561] Unwind augmentation on x86 is off by one instruction

https://bugs.llvm.org/show_bug.cgi?id=43561 Jaroslav Sevcik changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[lldb-dev] LLVM 10.0.1-rc1 release update

Hi, All the patches for LLVM 10.0.1-rc1 have been merged, and I'm just waiting for the CI jobs to finish. I will tag the release tomorrow if all goes well. Don't worry if you have a change that didn't make it into LLVM 10.0.1-rc1, there is still another month to merge changes before LLVM 10.0.1-

[lldb-dev] [Bug 45981] New: StringRef::getAsInteger doesn't support "+1"

https://bugs.llvm.org/show_bug.cgi?id=45981 Bug ID: 45981 Summary: StringRef::getAsInteger doesn't support "+1" Product: lldb Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement

Re: [lldb-dev] Unable to use Vi mode in LLDB console on Linux

bindings and LLDB does a bunch of bindings for custom >> things which you won't want to use. >> >>> On May 16, 2020, at 10:34 AM, Alvin Ye via lldb-dev >>> wrote: >>> >>> Hello, >>> >>> I'm using LLDB installed as Arch L

Re: [lldb-dev] Unable to use Vi mode in LLDB console on Linux

May 16, 2020, at 10:34 AM, Alvin Ye via lldb-dev > > wrote: > > > > Hello, > > > > I'm using LLDB installed as Arch Linux package. > > > > % lldb -v > > lldb version 10.0.0 > > > > % cat ~/.editrc > > bind -v > > > &g

Re: [lldb-dev] Pre-merge lldb testing

On Sat, May 16, 2020 at 12:18 PM Greg Clayton wrote: > > > On May 15, 2020, at 7:04 PM, Eric Christopher via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > Hi All, > > We've been testing[1] a number of patches upstream by default via some > pre-merge ch

Re: [lldb-dev] Unable to use Vi mode in LLDB console on Linux

There are some posts about issues with using the "bind -v". It seems it will delete all other key bindings and LLDB does a bunch of bindings for custom things which you won't want to use. > On May 16, 2020, at 10:34 AM, Alvin Ye via lldb-dev > wrote: > > Hello, &g

Re: [lldb-dev] Pre-merge lldb testing

> On May 15, 2020, at 7:04 PM, Eric Christopher via lldb-dev > wrote: > > Hi All, > > We've been testing[1] a number of patches upstream by default via some > pre-merge checks in phabricator. I was thinking of turning them on for lldb > as well. Mostly it well

[lldb-dev] Unable to use Vi mode in LLDB console on Linux

Hello, I'm using LLDB installed as Arch Linux package. % lldb -v lldb version 10.0.0 % cat ~/.editrc bind -v I'm not able to use vi keybindings like j, k cycle through commands in the lldb console. It would be great if someone could help me with this issue. Thanks, Alvin _

[lldb-dev] Pre-merge lldb testing

Hi All, We've been testing[1] a number of patches upstream by default via some pre-merge checks in phabricator. I was thinking of turning them on for lldb as well. Mostly it well just help people know whether or not they've broken lldb before they commit something, but won't stop committing or do

[lldb-dev] [Bug 45944] New: LLDB print wrong value for a parameter at Og

https://bugs.llvm.org/show_bug.cgi?id=45944 Bug ID: 45944 Summary: LLDB print wrong value for a parameter at Og Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Keywords: wrong-debug

Re: [lldb-dev] Is there a just-my-code like debugging mode for LLDB?

On 14/05/2020 11:56, Jaroslav Sevcik wrote: > > The svr4 support seems to be off by > default:  > https://github.com/llvm/llvm-project/blob/2974b3c566d68f1d7c907f891137cf0292dd35aa/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemoteProperties.td#L14 > > It would definitely make sense to turn

[lldb-dev] [Bug 45920] lldb wrongly stopped at a statement within a nested for statement by si (step instruction)

https://bugs.llvm.org/show_bug.cgi?id=45920 Jeremy Morse changed: What|Removed |Added Blocks||38768 Version|unspecified

Re: [lldb-dev] Is there a just-my-code like debugging mode for LLDB?

AM Pavel Labath via lldb-dev < lldb-dev@lists.llvm.org> wrote: > On 14/05/2020 03:50, Emre Kultursay via lldb-dev wrote: > > One thing I want to try is "settings set > > plugin.process.gdb-remote.use-libraries-svr4 true". > > Isn't that the default? T

Re: [lldb-dev] Is there a just-my-code like debugging mode for LLDB?

On 14/05/2020 03:50, Emre Kultursay via lldb-dev wrote: > One thing I want to try is "settings set > plugin.process.gdb-remote.use-libraries-svr4 true". Isn't that the default? The reason this setting was added was so we could test the !svr code path without forcibly disab

[lldb-dev] [Bug 45921] New: lldb not directly stopped at a specified statement

https://bugs.llvm.org/show_bug.cgi?id=45921 Bug ID: 45921 Summary: lldb not directly stopped at a specified statement Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhance

[lldb-dev] [Bug 45920] New: lldb wrongly stopped at a statement for nesting loop using step instruction

https://bugs.llvm.org/show_bug.cgi?id=45920 Bug ID: 45920 Summary: lldb wrongly stopped at a statement for nesting loop using step instruction Product: lldb Version: unspecified Hardware: PC OS: Linux

Re: [lldb-dev] Is there a just-my-code like debugging mode for LLDB?

deal with Android all the time at > Facebook... > > Greg > > On May 8, 2020, at 9:07 AM, Emre Kultursay via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > Hi lldb-dev, > > *TL;DR: *Has there been any efforts to introduce something like "Just My > Code" de

Re: [lldb-dev] Is there a just-my-code like debugging mode for LLDB?

One reason to not only load your libraries is backtraces will be truncated for any stack frames that go through the system libraries. These tend to be in the stack traces a lot as we deal with Android all the time at Facebook... Greg > On May 8, 2020, at 9:07 AM, Emre Kultursay via lldb-

Re: [lldb-dev] Is there a just-my-code like debugging mode for LLDB?

e cost is in parsing these libraries, we can look at parallelizing the > loading of all the device shared libraries first (prior to debugging) and > then launching when everything is pre-loaded. > > Greg > > >> On May 8, 2020, at 9:07 AM, Emre Kultursay via lldb-dev

Re: [lldb-dev] Is there a just-my-code like debugging mode for LLDB?

at parallelizing the loading of all the device shared libraries first (prior to debugging) and then launching when everything is pre-loaded. Greg > On May 8, 2020, at 9:07 AM, Emre Kultursay via lldb-dev > wrote: > > Hi lldb-dev, > > TL;DR: Has there been any efforts to

[lldb-dev] [Bug 45905] [lldb][unittest] Assertion failed : (m_replayers.find(RunID) == m_replayers.end())

https://bugs.llvm.org/show_bug.cgi?id=45905 Jonas Devlieghere changed: What|Removed |Added Assignee|lldb-dev@lists.llvm.org |jdevliegh...@apple.com -- You are receivin

[lldb-dev] [Bug 45905] New: [lldb][unittest] Assertion failed : (m_replayers.find(RunID) == m_replayers.end())

https://bugs.llvm.org/show_bug.cgi?id=45905 Bug ID: 45905 Summary: [lldb][unittest] Assertion failed : (m_replayers.find(RunID) == m_replayers.end()) Product: lldb Version: unspecified Hardware: PC OS: Windo

[lldb-dev] [Bug 45902] New: Wrong Debug Information at O3

https://bugs.llvm.org/show_bug.cgi?id=45902 Bug ID: 45902 Summary: Wrong Debug Information at O3 Product: lldb Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement P

[lldb-dev] [Bug 45894] New: LLDB LoadImageUsingPaths fails on 32bit arm linux platform

https://bugs.llvm.org/show_bug.cgi?id=45894 Bug ID: 45894 Summary: LLDB LoadImageUsingPaths fails on 32bit arm linux platform Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW

[lldb-dev] [Bug 41706] LLDB is broken on arm-linux-gnu-eabihf

https://bugs.llvm.org/show_bug.cgi?id=41706 Omair Javaid changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

[lldb-dev] [Bug 45893] New: Assert StackFrame Recognizer fails on arm-linux 32bit

https://bugs.llvm.org/show_bug.cgi?id=45893 Bug ID: 45893 Summary: Assert StackFrame Recognizer fails on arm-linux 32bit Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enha

[lldb-dev] [Bug 45892] New: LLDB fails to calculate backtrace from libc functions on arm

https://bugs.llvm.org/show_bug.cgi?id=45892 Bug ID: 45892 Summary: LLDB fails to calculate backtrace from libc functions on arm Product: lldb Version: unspecified Hardware: PC OS: Linux Status: N

Re: [lldb-dev] LLDB_PYTHON_HOME

>>>> is 3.4, so we can't use it yet. For LLDB on Windows we agreed that the >>>> benefits of using FindPython3 are worth bumping the minimum required CMake >>>> version (see lldb/CMakeLists.txt, line 2-4). Once LLVM moves to CMake 3.12 >>>> or la

[lldb-dev] [Bug 45886] New: Wrong variable value change during debugging at Og

https://bugs.llvm.org/show_bug.cgi?id=45886 Bug ID: 45886 Summary: Wrong variable value change during debugging at Og Product: lldb Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: en

[lldb-dev] [Bug 45883] Wrong Back Trace Information at O3

https://bugs.llvm.org/show_bug.cgi?id=45883 Jeremy Morse changed: What|Removed |Added CC||jdevliegh...@apple.com, |

Re: [lldb-dev] LLDB_PYTHON_HOME

>> On Thu, Feb 27, 2020 at 10:23 AM Jonas Devlieghere < >>>> jo...@devlieghere.com> wrote: >>>> >>>>> Hey Adrian, >>>>> >>>>> Config.h gets generated by expanding the corresponding CMake >>>>> v

Re: [lldb-dev] Is there a just-my-code like debugging mode for LLDB?

020 22:21, Jim Ingham via lldb-dev wrote: > Note, if you are reading the binaries out of memory from the device, and > don’t have local symbols, things go much more slowly.  gdb-remote is NOT > a high bandwidth protocol, and fetching all the symbols through a series > of memory re

[lldb-dev] [Bug 45869] New: ELF debug sections relocation not implemented for 32bit targets

https://bugs.llvm.org/show_bug.cgi?id=45869 Bug ID: 45869 Summary: ELF debug sections relocation not implemented for 32bit targets Product: lldb Version: unspecified Hardware: PC OS: Linux Status

[lldb-dev] [Bug 24737] CreateDuringInstructionStep is flaky on arm

https://bugs.llvm.org/show_bug.cgi?id=24737 Omair Javaid changed: What|Removed |Added Resolution|FIXED |WORKSFORME -- You are receiving this mail becau

[lldb-dev] [Bug 27868] Evaluating JITed expressions on arm cannot handle hard float ABI

https://bugs.llvm.org/show_bug.cgi?id=27868 Omair Javaid changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

[lldb-dev] [Bug 24737] CreateDuringInstructionStep is flaky on arm

https://bugs.llvm.org/show_bug.cgi?id=24737 Omair Javaid changed: What|Removed |Added CC||omair.jav...@linaro.org Status|NEW

[lldb-dev] [Bug 24739] single_step_only_steps_one_instruction tests are broken on arm and aarch64

https://bugs.llvm.org/show_bug.cgi?id=24739 Omair Javaid changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

[lldb-dev] [Bug 45856] New: UTF8 data printed differently before and after program start

https://bugs.llvm.org/show_bug.cgi?id=45856 Bug ID: 45856 Summary: UTF8 data printed differently before and after program start Product: lldb Version: unspecified Hardware: PC OS: All Status: NEW

[lldb-dev] [Bug 45853] New: lldb:buggy expression unit test

https://bugs.llvm.org/show_bug.cgi?id=45853 Bug ID: 45853 Summary: lldb:buggy expression unit test Product: lldb Version: 10.0 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P

Re: [lldb-dev] Is there a just-my-code like debugging mode for LLDB?

with this sort of progressive loading of library symbols. Jim > On May 8, 2020, at 9:07 AM, Emre Kultursay via lldb-dev > wrote: > > Hi lldb-dev, > > TL;DR: Has there been any efforts to introduce something like "Just My Code" > debugging on LLDB? Debugging

[lldb-dev] [Bug 45852] New: On i386, lldb prints "error: failed to launch or debug process" when trying to run any process

https://bugs.llvm.org/show_bug.cgi?id=45852 Bug ID: 45852 Summary: On i386, lldb prints "error: failed to launch or debug process" when trying to run any process Product: lldb Version: 10.0 Hardware: PC OS:

[lldb-dev] Is there a just-my-code like debugging mode for LLDB?

Hi lldb-dev, *TL;DR: *Has there been any efforts to introduce something like "Just My Code" debugging on LLDB? Debugging on Android would really benefit from this. *Details:* Native Android apps typically have a single .so file from the user, but load ~150 system libraries. When attaching LLDB

[lldb-dev] [Bug 45832] Wrong backtrace in lldb with optimized code [-Og]

https://bugs.llvm.org/show_bug.cgi?id=45832 Davide Italiano changed: What|Removed |Added Version|unspecified |trunk CC|

[lldb-dev] [Bug 45832] New: Wrong backtrace in lldb with optimized code [-Og]

https://bugs.llvm.org/show_bug.cgi?id=45832 Bug ID: 45832 Summary: Wrong backtrace in lldb with optimized code [-Og] Product: lldb Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancemen

[lldb-dev] 2020 US LLVM Developers' Meeting - Announcement & Feedback Needed

LLVM Community, The LLVM Foundation board has been continuing to discuss the upcoming 2020 US LLVM Developers' Meeting in San Jose, CA and the impact by COVID-19. This event is currently scheduled to occur on September 28-29, and special events on September 27. Last year’s US LLVM Developers’

Re: [lldb-dev] Question regarding argument types of "BreakpointHitCallback"

I understand. Thank you very much for the thorough explanation, Jim! 🙂 ― Vangelis > On 30 Apr 2020, at 23:38, Jim Ingham wrote: > > > >> On Apr 30, 2020, at 12:43 PM, Vangelis Tsiatsianas via lldb-dev >> mailto:lldb-dev@lists.llvm.org>> wrote: >>

Re: [lldb-dev] Question regarding argument types of "BreakpointHitCallback"

> On Apr 30, 2020, at 12:43 PM, Vangelis Tsiatsianas via lldb-dev > wrote: > > Thank you for the answer, Greg. > > I personally managed to work around the problem, although it confused me a > bit at first and took a while to figure out the cause. May I suggest the &g

Re: [lldb-dev] Question regarding argument types of "BreakpointHitCallback"

eviates the issue, despite the sign difference. ― Vangelis > On 30 Apr 2020, at 22:22, Greg Clayton wrote: > > > >> On Apr 30, 2020, at 8:50 AM, Vangelis Tsiatsianas via lldb-dev >> mailto:lldb-dev@lists.llvm.org>> wrote: >> >> Hello, >>

Re: [lldb-dev] Question regarding argument types of "BreakpointHitCallback"

> On Apr 30, 2020, at 8:50 AM, Vangelis Tsiatsianas via lldb-dev > wrote: > > Hello, > > I would like to ask a question regarding "BreakpointHitCallback", which is > declared as such: > > bool (*BreakpointHitCallback)(void *baton, >

Re: [lldb-dev] LLDB problems on remote debugging

On Apr 29, 2020, at 9:28 PM, Rui Hong mailto:hongru...@mails.ucas.ac.cn>> wrote: First I would like to express my appreciation and thanks to you all especially Greg Clayton and Ted Woodward! Your advice and guidance are quite useful for me! You’re welcome! *4. by the way, does GDB has similar

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

On 04/29/2020 01:19 PM, David Blaikie wrote: > 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 creatin

[lldb-dev] Question regarding argument types of "BreakpointHitCallback"

Hello, I would like to ask a question regarding "BreakpointHitCallback", which is declared as such: bool (*BreakpointHitCallback)(void *baton, StoppointCallbackContext *context, lldb::user_id_t break_id, ll

Re: [lldb-dev] LLDB problems on remote debugging

at it. Most people will run fully linked executables (these tend to have PT_LOAD segments) when they run on a simuilator, not an unlinked object file (these tend to not have PT_LOAD segments). It shouldn't be too hard to get a statically linked executable with the right ELF program headers (P

Re: [lldb-dev] LLDB problems on remote debugging

Hi LLDB devs, First I would like to express my appreciation and thanks to you all especially Greg Clayton and Ted Woodward! Your advice and guidance are quite useful for me! I've been working on other lldb problems and resume solving the "remote loading" issue now. I now fully understand the

[lldb-dev] [Bug 45543] Backport D77000, "[lldb] [PECOFF] Only use PECallFrameInfo on the one supported architecture", to 10.0.1

https://bugs.llvm.org/show_bug.cgi?id=45543 Tom Stellard changed: What|Removed |Added Assignee|lldb-dev@lists.llvm.org |jmole...@apple.com --- Comment #1 from Tom Stell

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 (& m

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

Hi, Thanks to everyone who provided feedback. I would like to propose a more detailed plan based on the everyone's comments. It seems like there was a strong preference to maintain the bug ID numbers, so this proposal tries to address that. TLDR; This proposes to maintain bug ID numbers by ov

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

On 4/25/20 10:02 PM, Mehdi AMINI via cfe-dev wrote: On Fri, Apr 24, 2020 at 12:04 PM Tom Stellard via llvm-dev mailto:llvm-...@lists.llvm.org>> wrote: On 04/24/2020 03:24 AM, Sam McCall wrote: > clangd's experience using github issues to track bugs (in a separate repo) has been

[lldb-dev] [Bug 45676] New: lldb wrongly stopped at a break statement when using step-by-step

https://bugs.llvm.org/show_bug.cgi?id=45676 Bug ID: 45676 Summary: lldb wrongly stopped at a break statement when using step-by-step Product: lldb Version: unspecified Hardware: PC OS: Linux Stat

[lldb-dev] [Bug 45675] New: source/Plugins/Process/Darwin/CFUtils.h:37:15: error: No 'return' statement

https://bugs.llvm.org/show_bug.cgi?id=45675 Bug ID: 45675 Summary: source/Plugins/Process/Darwin/CFUtils.h:37:15: error: No 'return' statement Product: lldb Version: 10.0 Hardware: PC OS: Linux S

[lldb-dev] [Bug 45669] New: I would like to control the remote communication port

https://bugs.llvm.org/show_bug.cgi?id=45669 Bug ID: 45669 Summary: I would like to control the remote communication port Product: lldb Version: unspecified Hardware: All OS: All Status: NEW Severity: enhan

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

On Fri, 24 Apr 2020 at 14:13, Sam McCall via cfe-dev wrote: > On Fri, Apr 24, 2020 at 9:03 PM Tom Stellard wrote: > >> On 04/24/2020 03:24 AM, Sam McCall wrote: >> > clangd's experience using github issues to track bugs (in a separate >> repo) has been very positive, and I'm glad you're pushing

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

On 04/24/2020 03:24 AM, Sam McCall wrote: > clangd's experience using github issues to track bugs (in a separate repo) > has been very positive, and I'm glad you're pushing on this! > > Part of this has been that our issue tracker has been scoped to our > subproject only, which is a scope that t

[lldb-dev] [Bug 45653] New: DWP_OP(_GNU)_entry_value not used correctly to display clobbered parameter value (in dwarf4 and dwarf5)

https://bugs.llvm.org/show_bug.cgi?id=45653 Bug ID: 45653 Summary: DWP_OP(_GNU)_entry_value not used correctly to display clobbered parameter value (in dwarf4 and dwarf5) Product: lldb Version: unspecified Hardware: PC

[lldb-dev] [Bug 45642] New: Step over misbehaves with multiple threads on Linux

https://bugs.llvm.org/show_bug.cgi?id=45642 Bug ID: 45642 Summary: Step over misbehaves with multiple threads on Linux Product: lldb Version: 10.0 Hardware: PC OS: Linux Status: NEW Severity: normal

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

On 4/22/20 2:35 PM, Richard Smith wrote: On Wed, 22 Apr 2020 at 09:45, Philip Reames via cfe-dev mailto:cfe-...@lists.llvm.org>> wrote: On 4/21/20 6:50 PM, Richard Smith wrote: On Tue, 21 Apr 2020 at 17:00, Tom Stellard via llvm-dev mailto:llvm-...@lists.llvm.org>> wrote:

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

On Wed, 22 Apr 2020 at 09:45, Philip Reames via cfe-dev < cfe-...@lists.llvm.org> wrote: > On 4/21/20 6:50 PM, Richard Smith wrote: > > On Tue, 21 Apr 2020 at 17:00, Tom Stellard via llvm-dev < > llvm-...@lists.llvm.org> wrote: > >> On 04/21/2020 03:36 PM, Richard Smith via llvm-dev wrote: >> > On

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

On 04/21/2020 03:36 PM, Richard Smith via llvm-dev wrote: > On Tue, 21 Apr 2020 at 11:04, Philip Reames via cfe-dev > mailto:cfe-...@lists.llvm.org>> wrote: > > +1 to James's take > > I'd prefer simplicity of implementation over perfection here. > > If we end up with two different bug n

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

On 04/21/2020 06:50 PM, Richard Smith wrote: > On Tue, 21 Apr 2020 at 17:00, Tom Stellard via llvm-dev > mailto:llvm-...@lists.llvm.org>> wrote: > > On 04/21/2020 03:36 PM, Richard Smith via llvm-dev wrote: > > On Tue, 21 Apr 2020 at 11:04, Philip Reames via cfe-dev > mailto:cfe-...@list

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

On 4/21/20 6:50 PM, Richard Smith wrote: On Tue, 21 Apr 2020 at 17:00, Tom Stellard via llvm-dev mailto:llvm-...@lists.llvm.org>> wrote: On 04/21/2020 03:36 PM, Richard Smith via llvm-dev wrote: > On Tue, 21 Apr 2020 at 11:04, Philip Reames via cfe-dev mailto:cfe-...@lists.llvm.org

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

Custom prefixes are intended for autolinks to external systems -- I suspect it would not work properly (but have not tested) if you used it to refer back to github itself. E.g. putting reverse links in issues you refer to, or closing an issue when writing "closes CUSTOM-123" in a commit message. O

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

to-linking PR1234 as well, which would just get even more confusing. On Wed, 22 Apr 2020 at 13:14, James Y Knight via lldb-dev < lldb-dev@lists.llvm.org> wrote: > GitHub canonically uses "#NNN" to refer to its bugs or pull requests, and > also supports "GH-NNN". We&

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

GitHub also supports custom prefixes for the issues. However, here is another limitation: the prefix must be at least 3 letters, so we cannot, for example, autolink PR1234 issues. Already asked whether this restriction could be lifted. On Wed, Apr 22, 2020 at 3:15 PM James Y Knight via llvm-dev w

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

GitHub canonically uses "#NNN" to refer to its bugs or pull requests, and also supports "GH-NNN". We'll want to switch to one of those schemes, so that automatic linking works properly. So, in that case, PR1234 == legacy issue, #1234 or GH-1234 == new issue. (See https://help.github.com/en/github/

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

Hi Konrad, Thanks for the scripts – look useful! For the record, here is the result of previous experiments https://github.com/asl/llvm-bugzilla/issues On Wed, Apr 22, 2020 at 2:21 PM Konrad Kleine via cfe-dev wrote: > > I wanted to try importing llvm bugs into a fresh github repo and here's my

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

I wanted to try importing llvm bugs into a fresh github repo and here's my result so far (import is still running): https://github.com/kwk/test-llvm-bz-import-4 . I've written the scripts ( https://github.com/kwk/bz2gh) myself because I wanted to remain in control and don't make my life more compli

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

Since Bugzilla numbers are all under 50,000 (at least for now:), can't we simply bump the GitHub issue/pull request numbers to 50,000, and start from there? Then it would be easy to identify: < 5 means Bugzilla, >= 5 means GitHub. Now somebody's only gotta find a way to file 5-200

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

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

-- Forwarded message - From: Konrad Kleine Date: Tue, 21 Apr 2020 at 09:39 Subject: Re: [llvm-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED] To: Tom Stellard Hi Tom. I haven't read all the replies before mine. Sorry if my idea overlaps with someone else's. I have

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

On Tue, 21 Apr 2020 at 17:00, Tom Stellard via llvm-dev < llvm-...@lists.llvm.org> wrote: > On 04/21/2020 03:36 PM, Richard Smith via llvm-dev wrote: > > On Tue, 21 Apr 2020 at 11:04, Philip Reames via cfe-dev < > cfe-...@lists.llvm.org > wrote: > > > > +1 to Jam

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

On 04/21/2020 03:36 PM, Richard Smith via llvm-dev wrote: > On Tue, 21 Apr 2020 at 11:04, Philip Reames via cfe-dev > mailto:cfe-...@lists.llvm.org>> wrote: > > +1 to James's take > > I'd prefer simplicity of implementation over perfection here. > > If we end up with two different bug n

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

On 4/21/20 3:36 PM, Richard Smith wrote: On Tue, 21 Apr 2020 at 11:04, Philip Reames via cfe-dev mailto:cfe-...@lists.llvm.org>> wrote: +1 to James's take I'd prefer simplicity of implementation over perfection here. If we end up with two different bug numbering systems, that's a pr

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

On Tue, 21 Apr 2020 at 11:04, Philip Reames via cfe-dev < cfe-...@lists.llvm.org> wrote: > +1 to James's take > > I'd prefer simplicity of implementation over perfection here. > If we end up with two different bug numbering systems, that's a problem that we will be paying for for many years. It's

[lldb-dev] LLVM 10.0.1 Release Schedule

Hi, Here is the proposed 10.0.1 release schedule. If there are no objections, I'll put it on the website. May 18: 10.0.1-rc1 Jun 18: 10.0.1-rc2 Jun 25: 10.0.1-final -Tom ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin

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

+1 to James's take I'd prefer simplicity of implementation over perfection here. Philip On 4/20/20 4:08 PM, James Y Knight via llvm-dev wrote: In a previous discussion, one other suggestion had been to migrate all the bugzilla bugs to a separate initially-private "bug archive" repository in g

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 mind

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

Hi James, > 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). Sorry, I missed the subcomponents for the tools when I did the migration of the labels. Will add them! -- With best regards, Anto

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] [llvm-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED]

> On 04/20/2020 04:08 PM, James Y Knight wrote: > > In a previous discussion, one other suggestion had been to migrate all the > > bugzilla bugs to a separate initially-private "bug archive" repository in > > github. This has a few benefits: > > 1. If the migration is messed up, the repo can be d

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

On 04/20/2020 04:08 PM, James Y Knight wrote: > In a previous discussion, one other suggestion had been to migrate all the > bugzilla bugs to a separate initially-private "bug archive" repository in > github. This has a few benefits: > 1. If the migration is messed up, the repo can be deleted, an

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

On 04/20/2020 09:15 PM, Mehdi AMINI wrote: > Hi, > > How is the user workflow to file bugs? Do we have some sort of template? Do > they have to pick a label? > We don't have any templates defined yet, we need someone to volunteer to do this. Users would not be required to pick a label, they wo

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

On 2020-04-20, Richard Smith via cfe-dev wrote: On Mon, 20 Apr 2020 at 13:57, Anton Korobeynikov via cfe-dev < cfe-...@lists.llvm.org> wrote: > If we are reasonably certain that no one would be opening new issues on GitHub while the migration is running... And pull requests (the numbering is co

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

In a previous discussion, one other suggestion had been to migrate all the bugzilla bugs to a separate initially-private "bug archive" repository in github. This has a few benefits: 1. If the migration is messed up, the repo can be deleted, and the process run again, until we get a result we like.

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

On Mon, 20 Apr 2020 at 13:57, Anton Korobeynikov via cfe-dev < cfe-...@lists.llvm.org> wrote: > > If we are reasonably certain that no one would be opening new issues on > GitHub while the migration is running... > And pull requests (the numbering is common for issues and pull > requests) as well.

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

> If we are reasonably certain that no one would be opening new issues on > GitHub while the migration is running... And pull requests (the numbering is common for issues and pull requests) as well. And we cannot disable pull requests at all. And I'm afraid the issues will need to be opened as wel

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

210 issues have been filed on github so far. That's negligible compared to the total number we have, so a minor additional effort for those seems acceptable if we can't actually clean them out and reuse the numbers. So suppose we start with bugzilla issue #211 and migrate the issues to github one

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

Just to clarify a bit: what I wanted to say is that it's unlikely that we will be able to ensure that bugzilla issue numbers after migration would coincide with github issue numbers. And therefore proper mapping will be necessary. And this mapping would be more complex than just rewriting the URL.

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

> Can we preserve the existing bug numbers if we migrate this way? There are > lots of references to "PRx" in checked in LLVM artifacts and elsewhere in > the world, as well as links to llvm.org/PRx, and if we can preserve all > the issue numbers this would ease the transition pain subst

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

On 04/20/2020 12:49 PM, Richard Smith wrote: > On Mon, 20 Apr 2020 at 12:31, Tom Stellard via llvm-dev > mailto:llvm-...@lists.llvm.org>> wrote: > > Hi, > > I wanted to continue discussing the plan to migrate from Bugzilla to > Github. > It was suggested that I start a new thread an

<    6   7   8   9   10   11   12   13   14   15   >