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

[Tom Stellard via lldb-dev]

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 overwriting existing GitHub 
issues
instead of creating new ones.  e.g. github.com/llvm/llvm-project/issues/1 will
be overwritten with data from llvm.org/PR1.  There will be some bugs that
end up having their data copied into pull requests, which may be strange,
but the data will be preserved and the IDs will be preserved and this would
only happen to very old bugs.

Proposal:

Detailed steps for doing the migration:


* Weeks or days before the migration:

1. Create a new GitHub repository called llvm-bug-archive and import bug
data from bugzilla.

This step should not be under any kind of time pressure, so that the conversion
process can be debugged and refined.

2. Install label notification system using GitHub actions and enable web hook
to send emails to llvm-bugs list.

* Day before the migration:

3. Make bugzilla readonly.

4. Import any new bugs created since the last import.

There may be commit access disruption during the migration, so 
completing these steps the day before will limit the amount of down time.

5. Temporarily re-enable issues in the llvm-project repo and copy existing 
issues
to the llvm-bug-archive repo so they get higher IDs numbers than any
existing PR.  Disable issues when done.

Note that we will copy issues instead of moving them, which means the original
issue will remain in tact.  This will allow us to retain the bug IDs
for future use and not 'lose' a bug ID.

* Day of migration:

6. Lockdown the repo as much as possible to prevent people from creating
issues or pull requests.

Temporarily making the repo private may be one way to achieve this.  Other
suggestions welcome.

7. Copy issues with overlapping issues IDs from the llvm-bug-archive repo
into the llvm-project repo.

Issues from the llvm-bug-archive repo that have the same ID number as
existing issues in the llvm-project repo will be manually copied from
the former to the later.  This will allow us to preserve the PR numbers
from bugzilla.  Here is an example for how this would work:

- Delete comments and description from llvm-project issue #1.
- Copy comments and description from llvm-bug-archive issue #1 into
  llvm-project issue #1.

Since GitHub issue and pull requests share the same numbering sequence, any
PR# from bugzilla that maps to a pull request in the llvm-project repo will
need to have it's comments copied into a pull request.  These issues will look 
slightly
strange since there will be random commits attached to the issue.  However,
all data will be preserved and more importantly the bug ID will be preserved.

The issues URL can be used to access pull requests e.g.
pull request #84 is accessible via github.com/llvm/llvm-project/issues/84
so even with bugzilla data stored in pull requests, we will still be able to do 
a simple redirect
from llvm.org/PR### to github.com/llvm/llvm-project/issues/###


8. Once all the overlapping Issue IDs have been copied.  Move the rest of the 
issues
from the llvm-bug-archive repo to the llvm-project repo.

This should be faster than doing the copies since we do not need to overwrite 
existing
issues and can just move the issues from one repo to the other.

The end result of this is that we have all the old bugs from bugzilla present 
as issues
in the llvm-project repository with all of their ID numbers preserved.


* Other action items:

- We need volunteers to help create bug templates to simplify the process of 
submitting
  bugs.  If you are interested in helping with this, let me know.

- Continue to iterate on the set of issue labels.  This should not block the 
migration since
labels can be changed at any time, but there were some suggested improvements 
that should
be discussed.


Please reply to this proposal with your questions, comments, praise, or 
concerns.

Thanks,
Tom


[1] 
https://help.github.com/en/github/building-a-strong-community/about-issue-and-pull-request-templates




On 04/20/2020 12:30 PM, Tom Stellard via llvm-dev wrote:
> Hi,
> 
> I wanted to continue discussing the plan to migrate from Bugzilla to Github.
> It was suggested that I start a new thread and give a summary of the proposal
> and what has changed since it was originally proposed in October.
> 
> == Here is the original proposal:
> 
> http://lists.llvm.org/pipermail/llvm-dev/2019-October/136162.html
> 
> == What has changed:
> 
> * You will be able to subscribe to notifications for a specific issue
>   labels.  We have a proof of concept notification system using github actions
>   that will be used for this.
> 
> * Emails will be sent to llvm-bugs when issues are opened or closed.
> 
> * We have the initial list of labels: 
> https://github.com/llvm/llvm-project/labels
> 
> == Remaini

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

[David Blaikie via lldb-dev]

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 (& maybe some padding) in a single/quick-ish (no idea how quickly
those can be created) window might help reduce the need for race
conditions/shutting down bug reporting, etc

On Wed, Apr 29, 2020 at 8:25 AM Tom Stellard via cfe-dev <
cfe-...@lists.llvm.org> wrote:

> 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 overwriting existing
> GitHub issues
> instead of creating new ones.  e.g. github.com/llvm/llvm-project/issues/1
> will
> be overwritten with data from llvm.org/PR1.  There will be some bugs that
> end up having their data copied into pull requests, which may be strange,
> but the data will be preserved and the IDs will be preserved and this would
> only happen to very old bugs.
>
> Proposal:
>
> Detailed steps for doing the migration:
>
>
> * Weeks or days before the migration:
>
> 1. Create a new GitHub repository called llvm-bug-archive and import bug
> data from bugzilla.
>
> This step should not be under any kind of time pressure, so that the
> conversion
> process can be debugged and refined.
>
> 2. Install label notification system using GitHub actions and enable web
> hook
> to send emails to llvm-bugs list.
>
> * Day before the migration:
>
> 3. Make bugzilla readonly.
>
> 4. Import any new bugs created since the last import.
>
> There may be commit access disruption during the migration, so
> completing these steps the day before will limit the amount of down time.
>
> 5. Temporarily re-enable issues in the llvm-project repo and copy existing
> issues
> to the llvm-bug-archive repo so they get higher IDs numbers than any
> existing PR.  Disable issues when done.
>
> Note that we will copy issues instead of moving them, which means the
> original
> issue will remain in tact.  This will allow us to retain the bug IDs
> for future use and not 'lose' a bug ID.
>
> * Day of migration:
>
> 6. Lockdown the repo as much as possible to prevent people from creating
> issues or pull requests.
>
> Temporarily making the repo private may be one way to achieve this.  Other
> suggestions welcome.
>
> 7. Copy issues with overlapping issues IDs from the llvm-bug-archive repo
> into the llvm-project repo.
>
> Issues from the llvm-bug-archive repo that have the same ID number as
> existing issues in the llvm-project repo will be manually copied from
> the former to the later.  This will allow us to preserve the PR numbers
> from bugzilla.  Here is an example for how this would work:
>
> - Delete comments and description from llvm-project issue #1.
> - Copy comments and description from llvm-bug-archive issue #1 into
>   llvm-project issue #1.
>
> Since GitHub issue and pull requests share the same numbering sequence, any
> PR# from bugzilla that maps to a pull request in the llvm-project repo will
> need to have it's comments copied into a pull request.  These issues will
> look slightly
> strange since there will be random commits attached to the issue.  However,
> all data will be preserved and more importantly the bug ID will be
> preserved.
>
> The issues URL can be used to access pull requests e.g.
> pull request #84 is accessible via github.com/llvm/llvm-project/issues/84
> so even with bugzilla data stored in pull requests, we will still be able
> to do a simple redirect
> from llvm.org/PR###  to
> github.com/llvm/llvm-project/issues/###
> 
>
>
> 8. Once all the overlapping Issue IDs have been copied.  Move the rest of
> the issues
> from the llvm-bug-archive repo to the llvm-project repo.
>
> This should be faster than doing the copies since we do not need to
> overwrite existing
> issues and can just move the issues from one repo to the other.
>
> The end result of this is that we have all the old bugs from bugzilla
> present as issues
> in the llvm-project repository with all of their ID numbers preserved.
>
>
> * Other action items:
>
> - We need volunteers to help create bug templates to simplify the process
> of submitting
>   bugs.  If you are interested in helping with this, let me know.
>
> - Continue to iterate on the set of issue labels.  This should not block
> the migration since
> labels can be changed at any time, but there were some suggested
> improvements that should
> be discussed.
>
>
> Please reply to this proposal with your questions, comments, praise, or
> concerns.
>
> Thanks,
> Tom
>
>
> [1]
> https://help.github.com/en/github/building-a-strong-commu

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

[via lldb-dev]

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 Stellard  ---
Hi Jason,

Is this safe to backport?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Rui Hong via lldb-dev]

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 "remote 
connection/execution"(what happens after gdb-remote and how 'c' or 's' controls 
the execution) and the only problem is how to load the program. My simulator 
starts this way :    ./sim --port 1234    It do not do the 
"loading program" job when specified with --port right now. In order to fit the 
old GDB style, I prefer to still let lldb to do the "loading binary" job.


To provide more information about my memory architecture : logically, the 
memory is a whole(one address space), but divided into PM(program memory, 
starting at address 0x0) and DM(data memory, starting at address 0x8000). 
When loading program, the .text section should be loaded into PM and the .data 
section should be loaded into DM, and nothing more. And yes, only one 
executable.


I've tried "target modules load --load"(I'm using lldb 7.0.1 and it implemented 
this command), but the sections to load are not loadable(not PT_LOAD) and 
triggers no RSP package exchange. So I tried "memory write --infile", it 
triggers a "qMemoryRegionInfo:0" packet to query memory region info and a "M" 
packet to write memory, but these two packet are not supported by my simulator 
right now. My simulator supports "X" packet not "M"! When using with the old 
GDB, "load" command in GDB triggers a few "X" packets


So I want to know:
1. How to let lldb send "X" packet(perhaps a command) and where is the 
corresponding code located?(to let my simulator support "M" packet is also OK, 
but using the existing code that handles "X" packet is much easier)
2. What's the actual difference between "X" packet and "M" packet?(I can't see 
any difference between them, from the packet specification on GDB website. "X" 
packet is "X addr,length:XX??" and "M" packet is "M addr,length:XX??", I 
thought even the data "XX??" seems to be encoded in the same way: two 
hexadecimal digits per byte, or perhaps I was wrong?)
3. Is letting my simulator support "qMemoryRegionInfo" packet enough to make 
lldb send the correct "X" or "M" packets?(extract .text and .data sections from 
my executable and send them to PM and DM addresses)
*4. by the way, does GDB has similar command like "log enable gdb-remote 
packets" in lldb to print all the RSP packet exchange?


Kind regards,
Rui





-- Original --
From: "Greg Clayton"https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev