Re: [lldb-dev] [RFC] Restructuring the (command) tests

[Konrad Kleine via lldb-dev]

Raphael, this sounds like a good idea.

Am Fr., 30. Aug. 2019 um 10:44 Uhr schrieb Raphael “Teemperor” Isemann via
lldb-dev :

> Hi all,
>
> I have to admit I’m getting a bit confused lately where to put tests.
> Especially for testing LLDB commands it’s not obvious where to put files as
> we test some commands directly in the top-level test folder (e.g. quit,
> help, settings), some are in /functionalities with a _command suffix (e.g.
> target), some are in /functionalities without any suffix (e.g. register),
> some tests are split by subcommand (process, frame) and some are in the
> top-level folder with the _command prefix (e.g. expression). This makes it
> hard to figure out where to find or create tests for specific commands.
> Also setting a LIT_FILTER for jus testing CommandObject* changes is not
> possible.
>
> I would propose we restructure at least the command tests into
> “test/commands/${command_name}/${subcommand_name_or_functionality}/“ such
> as “test/commands/process/launch”. The LIT_FILTER for these things would be
> “commands/“.
>
> I don’t see any disadvantages from this as
> * downstreams usually doesn’t fiddle around with the existing tests, so
> there should hopefully be no merge conflicts from this.
> * git blame can handle this change as we only move files/directories and
> don’t touch their contents.
> * it’s very little work to actually do this.
>
> I’m not sure if there is a need to restructure any other tests but I think
> if there are no objections in this thread, then I assume everyone can just
> take a few seconds and restructure their own tests.
>
> Cheers,
>
> - Raphael
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> 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

[lldb-dev] Setting breakpoint on file and function name doesn't work as expected.

[Konrad Kleine via lldb-dev]

Hello,

I noticed this behavior for LLDB under Linux when setting a breakpoint on a
file and a function name:

When doing "breakpoint set --file  --name ", the
 is that of the compile unit (CU) and not necessarily where the
function is defined. This is not what an end-user expects.

Take this simple example program:

$ cat foo.h
int foo(){ return 42; }

$ cat main.c
#include "foo.h"
int main(){return foo();}

$ clang -g main.c

As you can see, the function foo is defined in foo.h so it seems natural to
set a breakpoint on foo.h, doesn't it?

$ lldb -x -b -o "breakpoint set --file foo.h --name foo" ./a.out
(lldb) target create "./a.out"
Current executable set to './a.out' (x86_64).
(lldb) breakpoint set --file foo.h --name foo
Breakpoint 1: no locations (pending).
WARNING:  Unable to resolve breakpoint to any actual locations.

Apparently, LLDB cannot find the symbol like this. Let's try the only other
file that we have in the project:

$ lldb -x -b -o "breakpoint set --file main.c --name foo" ./a.out
(lldb) target create "./a.out"
Current executable set to './a.out' (x86_64).
(lldb) breakpoint set --file main.c --name foo
Breakpoint 1: where = a.out`foo + 4 at foo.h:1:12, address =
0x00401114

Isn't that remarkable? LLDB uses main.c as the file to search in but then
finds it in foo.h.

Let's recall what the parameters --file and --name mean:

   -n  ( --name  )
Set the breakpoint by function name.  Can be repeated multiple
times to make one breakpoint for multiple names

   -f  ( --file  )
Specifies the source file in which to set this breakpoint.
Note, by default lldb only looks for files that are #included if they use
the standard include file extensions.  To
set breakpoints on .c/.cpp/.m/.mm files that are #included, set
target.inline-breakpoint-strategy to "always".

Let's check if setting the target.inline-breakpoint strategy to "always"
changes something:

$ lldb -x -b  -o "settings set target.inline-breakpoint-strategy always" -o
"breakpoint set --file foo.h --name foo" ./a.out
(lldb) target create "./a.out"
Current executable set to './a.out' (x86_64).
(lldb) settings set target.inline-breakpoint-strategy always
(lldb) breakpoint set --file foo.h --name foo
Breakpoint 1: no locations (pending).
WARNING:  Unable to resolve breakpoint to any actual locations.

No, it didn't change anything.

The only evidence for my assumption that LLDB uses the CU's name for --file
is the DWARF dump:

$ llvm-dwarfdump a.out
a.out: file format ELF64-x86-64

.debug_info contents:
0x: Compile Unit: length = 0x0060 version = 0x0004 abbr_offset
= 0x addr_size = 0x08 (next unit at 0x0064)

0x000b: DW_TAG_compile_unit
  DW_AT_producer ("clang version 8.0.0 (Fedora 8.0.0-3.fc30)")
  DW_AT_language (DW_LANG_C99)
  DW_AT_name ("main.c")
  DW_AT_stmt_list (0x)
  DW_AT_comp_dir ("/home/kkleine")
  DW_AT_low_pc (0x00401110)
  DW_AT_high_pc (0x0040113a)

0x002a:   DW_TAG_subprogram
DW_AT_low_pc (0x00401110)
DW_AT_high_pc (0x0040111b)
DW_AT_frame_base (DW_OP_reg6 RBP)
DW_AT_name ("foo")
DW_AT_decl_file ("/home/kkleine/./foo.h")
DW_AT_decl_line (1)
DW_AT_type (0x005c "int")
DW_AT_external (true)

0x0043:   DW_TAG_subprogram
DW_AT_low_pc (0x00401120)
DW_AT_high_pc (0x0040113a)
DW_AT_frame_base (DW_OP_reg6 RBP)
DW_AT_name ("main")
DW_AT_decl_file ("/home/kkleine/main.c")
DW_AT_decl_line (2)
DW_AT_type (0x005c "int")
DW_AT_external (true)

0x005c:   DW_TAG_base_type
DW_AT_name ("int")
DW_AT_encoding (DW_ATE_signed)
DW_AT_byte_size (0x04)

As you can see, the DWARF is very small and simply. The function foo has a
DW_AT_decl_file which is probably used to report the breakpoint location
but for the actual filtering, it seems as if the CU is crucial for the
--file argument.

The only reasonable implementation for --file to me seems to be when
combined with the line number:

$ lldb -x -b  -o "breakpoint set --file foo.h --line 1" ./a.out
(lldb) target create "./a.out"
Current executable set to './a.out' (x86_64).
(lldb) breakpoint set --file foo.h --line 1
Breakpoint 1: where = a.out`foo + 4 at foo.h:1:12, address =
0x00401114

This works as expected.

For myself I think that the --file --name combination works not like an
end-user expects because in bigger projects you typically look at the
definition of foo and want to pause, when execution reaches this. You don't
care if a function is inlined or in which CU the function is located.
Moreover I think the DWARF actually supports more than enough inform

Re: [lldb-dev] Setting breakpoint on file and function name doesn't work as expected.

[Konrad Kleine via lldb-dev]

I read the LLDB troubleshooting page [1] and found interesting quotes:

> When setting breakpoints in implementation source files (.c, cpp, cxx,
.m, .mm, etc), LLDB by
> default will only search for compile units whose filename matches.
> [...]
>   % echo "settings set target.inline-breakpoint-strategy always" >>
~/.lldbinit
> This tells LLDB to always look in all compile units and search for
breakpoint locations
> by file and line even if the implementation file doesn’t match. Setting
breakpoints in header
> files always searches all compile units because inline functions are
commonly defined in
> header files and often cause multiple breakpoints to have source line
information that matches
> many header file paths.

In my email before I did this

$ lldb -x -b -o "breakpoint set --file foo.h --name foo" ./a.out

I now added the breakpoint strategy and ran the above command without the
-x in order to pick up
the LLDB init code. Still no luck.

[1]: https://lldb.llvm.org/use/troubleshooting.html#troubleshooting

Am Mo., 4. Nov. 2019 um 13:56 Uhr schrieb Konrad Kleine :

> Hello,
>
> I noticed this behavior for LLDB under Linux when setting a breakpoint on
> a file and a function name:
>
> When doing "breakpoint set --file  --name ", the
>  is that of the compile unit (CU) and not necessarily where the
> function is defined. This is not what an end-user expects.
>
> Take this simple example program:
>
> $ cat foo.h
> int foo(){ return 42; }
>
> $ cat main.c
> #include "foo.h"
> int main(){return foo();}
>
> $ clang -g main.c
>
> As you can see, the function foo is defined in foo.h so it seems natural
> to set a breakpoint on foo.h, doesn't it?
>
> $ lldb -x -b -o "breakpoint set --file foo.h --name foo" ./a.out
> (lldb) target create "./a.out"
> Current executable set to './a.out' (x86_64).
> (lldb) breakpoint set --file foo.h --name foo
> Breakpoint 1: no locations (pending).
> WARNING:  Unable to resolve breakpoint to any actual locations.
>
> Apparently, LLDB cannot find the symbol like this. Let's try the only
> other file that we have in the project:
>
> $ lldb -x -b -o "breakpoint set --file main.c --name foo" ./a.out
> (lldb) target create "./a.out"
> Current executable set to './a.out' (x86_64).
> (lldb) breakpoint set --file main.c --name foo
> Breakpoint 1: where = a.out`foo + 4 at foo.h:1:12, address =
> 0x00401114
>
> Isn't that remarkable? LLDB uses main.c as the file to search in but then
> finds it in foo.h.
>
> Let's recall what the parameters --file and --name mean:
>
>-n  ( --name  )
> Set the breakpoint by function name.  Can be repeated multiple
> times to make one breakpoint for multiple names
>
>-f  ( --file  )
> Specifies the source file in which to set this breakpoint.
> Note, by default lldb only looks for files that are #included if they use
> the standard include file extensions.  To
> set breakpoints on .c/.cpp/.m/.mm files that are #included,
> set target.inline-breakpoint-strategy to "always".
>
> Let's check if setting the target.inline-breakpoint strategy to "always"
> changes something:
>
> $ lldb -x -b  -o "settings set target.inline-breakpoint-strategy always"
> -o "breakpoint set --file foo.h --name foo" ./a.out
> (lldb) target create "./a.out"
> Current executable set to './a.out' (x86_64).
> (lldb) settings set target.inline-breakpoint-strategy always
> (lldb) breakpoint set --file foo.h --name foo
> Breakpoint 1: no locations (pending).
> WARNING:  Unable to resolve breakpoint to any actual locations.
>
> No, it didn't change anything.
>
> The only evidence for my assumption that LLDB uses the CU's name for
> --file is the DWARF dump:
>
> $ llvm-dwarfdump a.out
> a.out: file format ELF64-x86-64
>
> .debug_info contents:
> 0x: Compile Unit: length = 0x0060 version = 0x0004 abbr_offset
> = 0x addr_size = 0x08 (next unit at 0x0064)
>
> 0x000b: DW_TAG_compile_unit
>   DW_AT_producer ("clang version 8.0.0 (Fedora 8.0.0-3.fc30)")
>   DW_AT_language (DW_LANG_C99)
>   DW_AT_name ("main.c")
>   DW_AT_stmt_list (0x)
>   DW_AT_comp_dir ("/home/kkleine")
>   DW_AT_low_pc (0x00401110)
>   DW_AT_high_pc (0x0040113a)
>
> 0x002a:   DW_TAG_subprogram
> DW_AT_low_pc (0x00401110)
> DW_AT_high_pc (0x0040111b)
> DW_AT_frame_base (DW_OP_reg6 RBP)
> DW_AT_name ("foo")
> DW_AT_decl_file ("/home/kkleine/./foo.h")
> DW_AT_decl_line (1)
> DW_AT_type (0x005c "int")
> DW_AT_external (true)
>
> 0x0043:   DW_TAG_subprogram
> DW_AT_low_pc (0x00401120)
> DW_AT_high_pc (0x0040113a)
> DW_AT_frame_base (DW_OP_reg6 RBP)
> DW_AT_name ("main")
> DW_AT_decl_file ("/home/kkl

Re: [lldb-dev] Setting breakpoint on file and function name doesn't work as expected.

[Konrad Kleine via lldb-dev]

Jim,

thank you for the explanation. I'm trying to see the situation more from an
end user's perspective. When --file or -f have two different meanings
depending on how they are combined, that's bad IMHO.

>From what I read in your response I get the feeling that you assume a user
knows about the difference between CU and his or her source file and the
implications it can have when for example LTO is enabled and we make heavy
use of inlining. I see this as a problem because source-level debugging for
a function name and a file to an end user means exactly that, nomatter
where the function is inlined. Do you agree?

Konrad
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Setting breakpoint on file and function name doesn't work as expected.

[Konrad Kleine via lldb-dev]

Hi Jim,

Am Fr., 8. Nov. 2019 um 19:57 Uhr schrieb Jim Ingham :

>
>
> > On Nov 8, 2019, at 1:53 AM, Konrad Kleine  wrote:
> >
> > Jim,
> >
> > thank you for the explanation. I'm trying to see the situation more from
> an end user's perspective. When --file or -f have two different meanings
> depending on how they are combined, that's bad IMHO.
>
> I don't think that it is bad that the file parameter in a "file and line"
> breakpoint and the file parameter in a function name breakpoint have
> different meanings.  That might very well make sense when you think about
> the kind of search the breakpoint is likely to do.  But this does raise a
> problem with the documentation.
>

I think it is dangerous to make too many assumptions and given that people
are lazy I think even with a good piece of documentation people would still
get it wrong. To me this is similar to a documentation that says: When you
cross the street in this direction, go when the light is green. When you
cross the street in the other direction, go when the light is red. With any
documentation, no matter how accurate it is you will have people not read
it entirely. For example, I used -f -n in a way and it worked. Then I
enabled LTO and my debugging habits began to break.

 One way to do it is to try to list all the meanings for each option ("when
> used in conjunction with...")  I don't think there are actually enough
> variants that this will bloat the documentation over much, but that's
> something to watch out for.
>

For the time being and the code working the way it is I'm totally not
against any documentation updates.

>
> Another thing I've thought about doing is adding the ability to have help
> include one of the non-optional, non-overlapping options to the command, so
> you could say:
>
> (lldb) help break set -n
>
> and that would tell you that this is a "by function name" breakpoint, and
> in that case -n means...  That might help reduce the information overload,
> and give a better sense of what these complex commands do.
>
> As I said, it would have been better from a documentation standpoint to
> make all these different breakpoint commands sub-commands of "break
> set"("break set function", "break set file-and-line', etc...) but I think
> people would find that too verbose.
>
> >
> > From what I read in your response I get the feeling that you assume a
> user knows about the difference between CU and his or her source file and
> the implications it can have when for example LTO is enabled and we make
> heavy use of inlining. I see this as a problem because source-level
> debugging for a function name and a file to an end user means exactly that,
> nomatter where the function is inlined. Do you agree?
>
> I am not sure what you are asking me to agree to.
>

> (lldb) break set -n foo -f bar.*
>
> means "set the breakpoint on functions named foo DEFINED in the file
> "bar.*".
>

My example with foo() was very contrived but not unusual. Take any template
function for example:

// foo.h
int foo(){ return 42; }

template 
T twice(T arg) { return arg+arg; }

// main.cpp
#include "foo.h"
int main(){return twice(foo());}

When I want to break on the function twice() defined in foo.h I would go
for "-f foo.h -n twice" but I have to go for "-f main.cpp -n
twice". And in terms of DWARF, there's enough to let me do the first
variant:

DW_AT_name ("twice")
DW_AT_decl_file ("/home/kkleine/./foo.h")
DW_AT_decl_line (4)

Why don't we respect those DW_AT_decl_file and DW_AT_decl_line? Those are
always there, for inlining (with LTO), for templates and for regular
functions.


> It could mean other things in the context of inlining, for instance you
> might want to tell lldb to break on the function "foo" whenever it is
> inlined INTO the CU bar.*.  That's also a perfectly valid thing to do, and
> you might think "-n -f" was the combination to do that, but it is not what
> it does.


I understand that, the question, as I asked it above, is why we just search
by CU?


> Again, the feature was intended to disambiguate between different
> functions with the same name by definition site which the current
> definition does.  So in this sense the user will have to know what the -f
> means (and we do need some good solution for documenting this more
> clearly.)
>

> Back to your original query...  If the function is defined in a .h file,
> or gets inlined by LTO, this filtering is trickier, and I didn't implement
> that behavior when I implemented this breakpoint type.  So in that case,
> and in the case where LTO inlines a function, the feature isn't implemented
> correctly.


Okay, that's good to know.


> The -n searche always looks for out of line and inline instances when
> doing the search.  So we already get the searcher to all the instances.
>  You would just have to widen the search beyond "Does the CU match" to try
> to figure out where the inlined instance was defined.
>

I will take a look at the code but I already noticed that call to
Comp

[lldb-dev] breakpoint not hit on ppc64

[Konrad Kleine via lldb-dev]

Hi,

I'm on a machine like this:

Linux  #1 SMP Tue Feb 18 16:40:30 EST 2020 ppc64
ppc64 ppc64 GNU/Linux
Red Hat Enterprise Linux Server release 7.8 (Maipo)

It seems that on PPC64 breakpoints are not able to hit, and it doesn't
matter which strategy you choose. Here's an example:

$ scl enable llvm-toolset-9.0 bash

$ clang++ --version
clang version 9.0.1 (Red Hat 9.0.1-1.el7)
Target: powerpc64-unknown-linux-gnu
Thread model: posix
InstalledDir: /opt/rh/llvm-toolset-9.0/root/usr/bin

$ echo "int main() { return 42; }" > ~/42.cpp

$ clang++ -g ~/42.cpp

Here's an example to set breakpoint by function name:

$ lldb -x -b -o "b main" -o "run" a.out
(lldb) target create "a.out"
Current executable set to 'a.out' (powerpc64le).
(lldb) b main
Breakpoint 1: 2 locations.
(lldb) run
Process 3279 exited with status = 42 (0x002a)

Process 3279 launched: '/root/a.out' (powerpc64le)
(lldb)

Please also notice that the process is identified as "powerpc64le"
even though this is a "powerpc64" machine.

The "-b" flag doesn't cause lldb to exit for some reason as well.

I hope someone with more experience than me with ppc64 can enlighten this:

Here are some findings:

* I'm testing now if the error remains to exist in LLVM master (a day
old or so). Then I will continue with looking at the findings further
below.

* Apparently ‘target list’ gets the architecture wrong and outputs
“ppc64le” instead of “ppc64”. Tom S. found out that this is because
there’s a problem with a list of architectures that’s being search
linearly: 
https://github.com/llvm/llvm-project/blob/0ce3b710b49c7b9ab837d220547aec92564dd78d/lldb/source/Utility/ArchSpec.cpp#L402

* I found that maybe the bug was introduced by this patch but I'm
still validating this: Add initial support to PowerPC64 little endian
(POWER8)
https://reviews.llvm.org/D36804

* I have written a test that just reproduces the wrong identification
of ppc64le instead of ppc64:

https://gist.github.com/kwk/a5febc24fae07f23022d2ff430667cfb

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Konrad Kleine via lldb-dev]

-- 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 a proposal for the issue migration from bugzilla to github. You
mentioned in the ML thread that proposal 1 and 2 were favored because they
can be done sooner than proposal 3.

In order to begin with proposal 1 and 2, what if you created dummy issues
in github for the number of bug-ranges 1-X, where X is the highest
number in bugzilla? When this is done by a script you could add a special
label to those issues that mark them as bugs that are still managed by
bugzilla. For the description you could put the link to the bugzilla
instance and a text that "this bug is still managed by bugzilla".

If you immediately close those bugs, then they don't show up. BUT IIRC
github has this odd way of numbering bugs and issues. Issues and Pull
Requests share the same pool of numbers. I'm sure you know that. But as
long as you disallow creation of NEW bugs in bugzilla, have created the
dummy issues in github, and don't open any PR in github this should be good.

Then at some point you can move over all the bugs in bugzilla to their
dummy issues in github. The latter just serve as placeholders until then.

I hope this makes sense.

Regards
Konrad

On Mon, 20 Apr 2020 at 21:30, Tom Stellard via llvm-dev <
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 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
>
> == Remaining issue:
>
> * There is one remaining issue that I don't feel we have consensus on,
> and that is what to do with bugs in the existing bugzilla.  Here are some
> options
> that we have discussed:
>
> 1. Switch to GitHub issues for new bugs only.  Bugs filed in bugzilla that
> are
> still active will be updated there until they are closed.  This means that
> over
> time the number of active bugs in bugzilla will slowly decrease as bugs
> are closed
> out.  Then at some point in the future, all of the bugs from bugzilla will
> be archived
> into their own GitHub repository that is separate from the llvm-project
> repo.
>
> 2. Same as 1, but also create a migration script that would allow anyone to
> manually migrate an active bug from bugzilla to a GitHub issue in the
> llvm-project
> repo.  The intention with this script is that it would be used to migrate
> high-traffic
> or important bugs from bugzilla to GitHub to help increase the visibility
> of the bug.
> This would not be used for mass migration of all the bugs.
>
> 3. Do a mass bug migration from bugzilla to GitHub and enable GitHub
> issues at the same time.
> Closed or inactive bugs would be archived into their own GitHub
> repository, and active bugs
> would be migrated to the llvm-project repo.
>
>
> The key difference between proposal 1,2 and 3, is when bugs will be
> archived from bugzilla
> to GitHub.  Delaying the archiving of bugs (proposals 1 and 2) means that
> we can migrate
> to GitHub issues sooner (within 1-2 weeks), whereas trying to archive bugs
> during the
> transition (proposal 3) will delay the transition for a while (likely
> several months)
> while we evaluate the various solutions for moving bugs from bugzilla to
> GitHub.
>
>
> The original proposal was to do 1 or 2, however there were some concerns
> raised on the list
> that having 2 different places to search for bugs for some period of time
> would
> be very inconvenient.  So, I would like to restart this discussion and
> hopefully we can
> come to some kind of conclusion about the best way forward.
>
> Thanks,
> Tom
>
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Konrad Kleine via lldb-dev]

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 complicated than it needs to be. The README.md
describes in great length what's imported and how. For now I import the
bugzillas just as placeholder issues. Then I lock those issues in github to
avoid messing with them. Before I created labels based on
/. Those are assigned to each issue. It should give
a good start to at least reserve all github #IDs so they map 1:1 to LLVM
BZs.

On Wed, 22 Apr 2020 at 09:23, Dimitry Andric via cfe-dev <
cfe-...@lists.llvm.org> wrote:

> 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 bogus GitHub
> tickets. :)  (Or ask GitHub support to bump the number synthetically.)
>
> -Dimitry
>
> On 22 Apr 2020, at 09:10, James Henderson via cfe-dev <
> cfe-...@lists.llvm.org> wrote:
>
> 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 referred to. This would often mean having to go to each in
> turn and seeing if the corresponding bug looked like it had anything to do
> with the related topic. Fortunately, given that there were many other
> things using the same bugzilla instances, this was usually pretty clear,
> but not always. Typos in bug numbers sometimes made things even harder,
> since you had to spend three times as long trying to guess.
>
> In other words +1 to using unique numbers, however we do it.
>
> On Wed, 22 Apr 2020 at 03:44, Johannes Doerfert via cfe-dev <
> cfe-...@lists.llvm.org> wrote:
>
>>
>> On 4/21/20 7:00 PM, Tom Stellard via llvm-dev 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 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 worth some
>> investment now to avoid that problem. And it doesn't seem like it really
>> requires much investment.
>> >>
>> >> Here's another path we could take:
>> >>
>> >> 1) Fork the llvm repository to a private "bugs" repository. Mirror the
>> bugzilla issues there. Iterate until we're happy, as per James's proposal.
>> >> 2) Sync the forked repository to the llvm repository, delete the llvm
>> repository, rename "bugs" to "llvm", and make it public.
>> >>
>> >> Then we'll have the first N bugs in llvm-project/llvm being *exactly*
>> the bugzilla bugs, and we'll have excised the existing github issues that
>> we want to pretend never existed anyway.
>> >>
>> >>
>> >> I think we've missed an important step in the planning here: we've not
>> agreed on a set of goals for the transition. Here are mine:
>> >>
>> >>   * We end up with one single issue tracking system containing all
>> issues, both old and new, both open and closed.
>> >>   * All links and references to existing bugs still work.
>> >>   * We have a single bug numbering system covering all bugs, and old
>> bugs retain their numbers.
>> > Why are the bug numbers important?  Could you help give some example
>> use cases that require having
>> > a non-intersecting set of bug numbers for bugzilla bugs and github
>> issues?
>>
>>
>> While I have no experience in bugzilla or github tooling, the two step
>> process described by Richard doesn't seem to be very complicated.
>>
>>
>> As mentioned by others, we have commits and tests (and sometimes source
>> files) that explicitly mention bug numbers. I do regularly look up bugs
>> from a decade ago to determine if a test or some code still has
>> relevance or not. If PR3214 can be one of two bugs, it does not only
>> increase lookup time but also add confusion to everyone involved.
>>
>>
>> Cheers,
>>
>>Johannes
>>
>>
>>
>> > -Tom
>> >
>> >
>> >> It sounds like we don't all agree that the last point is important,
>> but if we can achieve it without any significant additional cost, why not
>> do so?
>> >>
>> >>  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 github. This has a few benef