Re: [lldb-dev] LLDB/NetBSD test suite results as of 8 Dec 2015
On 7 December 2015 at 19:28, Kamil Rytarowski via lldb-dev wrote: > > I ran the LLDB test suite of the LLDB-current version on NetBSD/amd64 > (v. 7.99.21). > > The results are as follows: > > 415 out of 415 test suites processed - TestRecursiveTypes.py > > Ran 415 test suites (266 failed) (64.096386%) > Ran 222 test cases (145 failed) (65.315315%) > Failing Tests (266) > > The major missing piece is native process tracking support (with the > ptrace(2) interface). Once added, LLDB should start to be usable on > this platform. Great progress, and thanks for the update! Are you planning to base the NetBSD native support on NativeProcessLinux? I need to migrate the FreeBSD support to work that way still. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Auditing dotest's command line options
Hi Greg, Take a look at dotest.py next time you get some free time and let me know what you think. There should be no more globals. Everything that used to be a global is now stored in its own module `configuration.py`, and everything in `configuration.py` can be referenced from everywhere in the entire test suite. On Fri, Nov 20, 2015 at 10:34 AM Greg Clayton wrote: > Zach, I would also like to get rid of all global variables in the process > of this change. The history goes like this: a long time ago someone wrote > the initial dotest.py and parsed the options manually and stored results in > global variables. Later, someone converted the options over to use a python > library to parse the options, but we mostly copied the options from the > options dictionary over into the globals and still use the globals all over > the code. It would be great if we had at most one global variable that is > something like "g_options" and anyone that was using any global variables > will switch over to use the "g_options." instead. Then we don't have to > make copies and we can let the g_options contain all settings that are > required. > > > On Nov 18, 2015, at 2:32 PM, Zachary Turner via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > I would like to do a complete audit of dotest's command line options, > find out who's using what, and then potentially delete anything that isn't > being used. There's a mess of command line options in use, to the point > that it's often hard to find free letters to use for new options. > > > > I created this spreadsheet with a complete list of command line options, > their descriptions, and a place for people to enter what options they're > using or do not want to be deleted. > > > > > https://docs.google.com/spreadsheets/d/1wkxAY7l0_cJOHhhsSlh3aKKlQShlX1D7X1Dn8kpqxy4/edit?usp=sharing > > > > If someone has already written YES in the box that indicates they need > the option, please don't overwrite it. If you write YES in a box, please > provide at least a small rationale for why this option is useful to you. > Feel free to add additional rationale if someone has already added some > rationale. > > > > I'm going to have a couple days in mid-December and do this cleanup, so > I'd like to get a solid picture of what options are not needed before > then. After people have had some time to look over this, I'll go through > the results and decide what to do with each one, and then send out another > email with a proposed action column for each command line option. > > > > Please do take the time to have a look at this, because any option that > doesn't have a YES in it after a couple of weeks I'm going to assume is a > candidate for deletion. > > > > > > ___ > > lldb-dev mailing list > > lldb-dev@lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Auditing dotest's command line options
Do we not want to have an "options" global variable in this module that contains everything instead of having separate global variables in this file? The idea would be that you could assign directly when parsing arguments: (configuration.options, args) = parser.parse_args(sys.argv[1:]) Its OK if we don't do this, but this is what I was originally thinking. Then we don't need to do any transfer out of the options dictionary that is returned by the option parser. The drawback with this approach is the "configuration.options" would probably need to be initialized in case someone tries to access the "configuration.options" without first parsing arguments. So in that respect the global approach is nicer. Greg > On Dec 8, 2015, at 10:45 AM, Zachary Turner wrote: > > Hi Greg, > > Take a look at dotest.py next time you get some free time and let me know > what you think. There should be no more globals. Everything that used to be > a global is now stored in its own module `configuration.py`, and everything > in `configuration.py` can be referenced from everywhere in the entire test > suite. > > On Fri, Nov 20, 2015 at 10:34 AM Greg Clayton wrote: > Zach, I would also like to get rid of all global variables in the process of > this change. The history goes like this: a long time ago someone wrote the > initial dotest.py and parsed the options manually and stored results in > global variables. Later, someone converted the options over to use a python > library to parse the options, but we mostly copied the options from the > options dictionary over into the globals and still use the globals all over > the code. It would be great if we had at most one global variable that is > something like "g_options" and anyone that was using any global variables > will switch over to use the "g_options." instead. Then we don't have to > make copies and we can let the g_options contain all settings that are > required. > > > On Nov 18, 2015, at 2:32 PM, Zachary Turner via lldb-dev > > wrote: > > > > I would like to do a complete audit of dotest's command line options, find > > out who's using what, and then potentially delete anything that isn't being > > used. There's a mess of command line options in use, to the point that > > it's often hard to find free letters to use for new options. > > > > I created this spreadsheet with a complete list of command line options, > > their descriptions, and a place for people to enter what options they're > > using or do not want to be deleted. > > > > https://docs.google.com/spreadsheets/d/1wkxAY7l0_cJOHhhsSlh3aKKlQShlX1D7X1Dn8kpqxy4/edit?usp=sharing > > > > If someone has already written YES in the box that indicates they need the > > option, please don't overwrite it. If you write YES in a box, please > > provide at least a small rationale for why this option is useful to you. > > Feel free to add additional rationale if someone has already added some > > rationale. > > > > I'm going to have a couple days in mid-December and do this cleanup, so I'd > > like to get a solid picture of what options are not needed before then. > > After people have had some time to look over this, I'll go through the > > results and decide what to do with each one, and then send out another > > email with a proposed action column for each command line option. > > > > Please do take the time to have a look at this, because any option that > > doesn't have a YES in it after a couple of weeks I'm going to assume is a > > candidate for deletion. > > > > > > ___ > > lldb-dev mailing list > > lldb-dev@lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Auditing dotest's command line options
There's no way to avoid doing a transfer out of the options dictionary at some level, because it's not a straight transfer. There's a ton of post-processing that gets done on the options dictionary in order to convert the raw options into a useful format. That might be solvable with more advanced use of argparse. This approach does get rid of one level of option transfer though. Because we would transfer 1. From the class returned by argparse into the global 2. From the global into the lldb module Now we only transfer from the argparse class into the `configuration` module, and everything else just uses that. On Tue, Dec 8, 2015 at 10:52 AM Greg Clayton wrote: > Do we not want to have an "options" global variable in this module that > contains everything instead of having separate global variables in this > file? The idea would be that you could assign directly when parsing > arguments: > > (configuration.options, args) = parser.parse_args(sys.argv[1:]) > > Its OK if we don't do this, but this is what I was originally thinking. > Then we don't need to do any transfer out of the options dictionary that is > returned by the option parser. The drawback with this approach is the > "configuration.options" would probably need to be initialized in case > someone tries to access the "configuration.options" without first parsing > arguments. So in that respect the global approach is nicer. > > Greg > > > On Dec 8, 2015, at 10:45 AM, Zachary Turner wrote: > > > > Hi Greg, > > > > Take a look at dotest.py next time you get some free time and let me > know what you think. There should be no more globals. Everything that > used to be a global is now stored in its own module `configuration.py`, and > everything in `configuration.py` can be referenced from everywhere in the > entire test suite. > > > > On Fri, Nov 20, 2015 at 10:34 AM Greg Clayton > wrote: > > Zach, I would also like to get rid of all global variables in the > process of this change. The history goes like this: a long time ago someone > wrote the initial dotest.py and parsed the options manually and stored > results in global variables. Later, someone converted the options over to > use a python library to parse the options, but we mostly copied the options > from the options dictionary over into the globals and still use the globals > all over the code. It would be great if we had at most one global variable > that is something like "g_options" and anyone that was using any global > variables will switch over to use the "g_options." instead. Then we > don't have to make copies and we can let the g_options contain all settings > that are required. > > > > > On Nov 18, 2015, at 2:32 PM, Zachary Turner via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > > > I would like to do a complete audit of dotest's command line options, > find out who's using what, and then potentially delete anything that isn't > being used. There's a mess of command line options in use, to the point > that it's often hard to find free letters to use for new options. > > > > > > I created this spreadsheet with a complete list of command line > options, their descriptions, and a place for people to enter what options > they're using or do not want to be deleted. > > > > > > > https://docs.google.com/spreadsheets/d/1wkxAY7l0_cJOHhhsSlh3aKKlQShlX1D7X1Dn8kpqxy4/edit?usp=sharing > > > > > > If someone has already written YES in the box that indicates they need > the option, please don't overwrite it. If you write YES in a box, please > provide at least a small rationale for why this option is useful to you. > Feel free to add additional rationale if someone has already added some > rationale. > > > > > > I'm going to have a couple days in mid-December and do this cleanup, > so I'd like to get a solid picture of what options are not needed before > then. After people have had some time to look over this, I'll go through > the results and decide what to do with each one, and then send out another > email with a proposed action column for each command line option. > > > > > > Please do take the time to have a look at this, because any option > that doesn't have a YES in it after a couple of weeks I'm going to assume > is a candidate for deletion. > > > > > > > > > ___ > > > lldb-dev mailing list > > > lldb-dev@lists.llvm.org > > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > > > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Auditing dotest's command line options
One advantage of this approach is that it makes the options available to the entire test suite. Even if we have no transferring going on, and we get argparse to return us a perfectly organized structure with everything in the right format, in order to make all the options accessible to the rest of the test suite, we still need to stick it in a global module somewhere. And then you would write `configuration.options.test_categories`, whereas with this approach we just write `configuration.test_categories`. It's a minor point, but I like the shorter member access personally. On Tue, Dec 8, 2015 at 11:07 AM Zachary Turner wrote: > There's no way to avoid doing a transfer out of the options dictionary at > some level, because it's not a straight transfer. There's a ton of > post-processing that gets done on the options dictionary in order to > convert the raw options into a useful format. > > That might be solvable with more advanced use of argparse. This approach > does get rid of one level of option transfer though. Because we would > transfer > 1. From the class returned by argparse into the global > 2. From the global into the lldb module > > Now we only transfer from the argparse class into the `configuration` > module, and everything else just uses that. > > > On Tue, Dec 8, 2015 at 10:52 AM Greg Clayton wrote: > >> Do we not want to have an "options" global variable in this module that >> contains everything instead of having separate global variables in this >> file? The idea would be that you could assign directly when parsing >> arguments: >> >> (configuration.options, args) = parser.parse_args(sys.argv[1:]) >> >> Its OK if we don't do this, but this is what I was originally thinking. >> Then we don't need to do any transfer out of the options dictionary that is >> returned by the option parser. The drawback with this approach is the >> "configuration.options" would probably need to be initialized in case >> someone tries to access the "configuration.options" without first parsing >> arguments. So in that respect the global approach is nicer. >> >> Greg >> >> > On Dec 8, 2015, at 10:45 AM, Zachary Turner wrote: >> > >> > Hi Greg, >> > >> > Take a look at dotest.py next time you get some free time and let me >> know what you think. There should be no more globals. Everything that >> used to be a global is now stored in its own module `configuration.py`, and >> everything in `configuration.py` can be referenced from everywhere in the >> entire test suite. >> > >> > On Fri, Nov 20, 2015 at 10:34 AM Greg Clayton >> wrote: >> > Zach, I would also like to get rid of all global variables in the >> process of this change. The history goes like this: a long time ago someone >> wrote the initial dotest.py and parsed the options manually and stored >> results in global variables. Later, someone converted the options over to >> use a python library to parse the options, but we mostly copied the options >> from the options dictionary over into the globals and still use the globals >> all over the code. It would be great if we had at most one global variable >> that is something like "g_options" and anyone that was using any global >> variables will switch over to use the "g_options." instead. Then we >> don't have to make copies and we can let the g_options contain all settings >> that are required. >> > >> > > On Nov 18, 2015, at 2:32 PM, Zachary Turner via lldb-dev < >> lldb-dev@lists.llvm.org> wrote: >> > > >> > > I would like to do a complete audit of dotest's command line options, >> find out who's using what, and then potentially delete anything that isn't >> being used. There's a mess of command line options in use, to the point >> that it's often hard to find free letters to use for new options. >> > > >> > > I created this spreadsheet with a complete list of command line >> options, their descriptions, and a place for people to enter what options >> they're using or do not want to be deleted. >> > > >> > > >> https://docs.google.com/spreadsheets/d/1wkxAY7l0_cJOHhhsSlh3aKKlQShlX1D7X1Dn8kpqxy4/edit?usp=sharing >> > > >> > > If someone has already written YES in the box that indicates they >> need the option, please don't overwrite it. If you write YES in a box, >> please provide at least a small rationale for why this option is useful to >> you. Feel free to add additional rationale if someone has already added >> some rationale. >> > > >> > > I'm going to have a couple days in mid-December and do this cleanup, >> so I'd like to get a solid picture of what options are not needed before >> then. After people have had some time to look over this, I'll go through >> the results and decide what to do with each one, and then send out another >> email with a proposed action column for each command line option. >> > > >> > > Please do take the time to have a look at this, because any option >> that doesn't have a YES in it after a couple of weeks I'm going to assume >> is a candidate for del
Re: [lldb-dev] Auditing dotest's command line options
Sounds good, looks good then. > On Dec 8, 2015, at 11:09 AM, Zachary Turner wrote: > > One advantage of this approach is that it makes the options available to the > entire test suite. Even if we have no transferring going on, and we get > argparse to return us a perfectly organized structure with everything in the > right format, in order to make all the options accessible to the rest of the > test suite, we still need to stick it in a global module somewhere. And then > you would write `configuration.options.test_categories`, whereas with this > approach we just write `configuration.test_categories`. It's a minor point, > but I like the shorter member access personally. > > On Tue, Dec 8, 2015 at 11:07 AM Zachary Turner wrote: > There's no way to avoid doing a transfer out of the options dictionary at > some level, because it's not a straight transfer. There's a ton of > post-processing that gets done on the options dictionary in order to convert > the raw options into a useful format. > > That might be solvable with more advanced use of argparse. This approach > does get rid of one level of option transfer though. Because we would > transfer > 1. From the class returned by argparse into the global > 2. From the global into the lldb module > > Now we only transfer from the argparse class into the `configuration` module, > and everything else just uses that. > > > On Tue, Dec 8, 2015 at 10:52 AM Greg Clayton wrote: > Do we not want to have an "options" global variable in this module that > contains everything instead of having separate global variables in this file? > The idea would be that you could assign directly when parsing arguments: > > (configuration.options, args) = parser.parse_args(sys.argv[1:]) > > Its OK if we don't do this, but this is what I was originally thinking. Then > we don't need to do any transfer out of the options dictionary that is > returned by the option parser. The drawback with this approach is the > "configuration.options" would probably need to be initialized in case someone > tries to access the "configuration.options" without first parsing arguments. > So in that respect the global approach is nicer. > > Greg > > > On Dec 8, 2015, at 10:45 AM, Zachary Turner wrote: > > > > Hi Greg, > > > > Take a look at dotest.py next time you get some free time and let me know > > what you think. There should be no more globals. Everything that used to > > be a global is now stored in its own module `configuration.py`, and > > everything in `configuration.py` can be referenced from everywhere in the > > entire test suite. > > > > On Fri, Nov 20, 2015 at 10:34 AM Greg Clayton wrote: > > Zach, I would also like to get rid of all global variables in the process > > of this change. The history goes like this: a long time ago someone wrote > > the initial dotest.py and parsed the options manually and stored results in > > global variables. Later, someone converted the options over to use a python > > library to parse the options, but we mostly copied the options from the > > options dictionary over into the globals and still use the globals all over > > the code. It would be great if we had at most one global variable that is > > something like "g_options" and anyone that was using any global variables > > will switch over to use the "g_options." instead. Then we don't have to > > make copies and we can let the g_options contain all settings that are > > required. > > > > > On Nov 18, 2015, at 2:32 PM, Zachary Turner via lldb-dev > > > wrote: > > > > > > I would like to do a complete audit of dotest's command line options, > > > find out who's using what, and then potentially delete anything that > > > isn't being used. There's a mess of command line options in use, to the > > > point that it's often hard to find free letters to use for new options. > > > > > > I created this spreadsheet with a complete list of command line options, > > > their descriptions, and a place for people to enter what options they're > > > using or do not want to be deleted. > > > > > > https://docs.google.com/spreadsheets/d/1wkxAY7l0_cJOHhhsSlh3aKKlQShlX1D7X1Dn8kpqxy4/edit?usp=sharing > > > > > > If someone has already written YES in the box that indicates they need > > > the option, please don't overwrite it. If you write YES in a box, please > > > provide at least a small rationale for why this option is useful to you. > > > Feel free to add additional rationale if someone has already added some > > > rationale. > > > > > > I'm going to have a couple days in mid-December and do this cleanup, so > > > I'd like to get a solid picture of what options are not needed before > > > then. After people have had some time to look over this, I'll go through > > > the results and decide what to do with each one, and then send out > > > another email with a proposed action column for each command line option. > > > > > > Please do take the time
Re: [lldb-dev] Linux core dump doesn't show listing when loaded
I don't think we should automatically print a backtrace after the target
create; just the stop reason and source (or disassembly) listing, ideally only
for the crashed thread.
Conceptually, we're loading the core file and attaching, and get a stopped
state. The state should be completely read-only - no running, changing memory,
registers, etc.
Process::LoadCore() shows this:
// We successfully loaded a core file, now pretend we stopped so we can
// show all of the threads in the core file and explore the crashed
// state.
SetPrivateState (eStateStopped);
Process::LoadCore() also acts like we're attaching:
DynamicLoader *dyld = GetDynamicLoader ();
if (dyld)
dyld->DidAttach();
GetJITLoaders().DidAttach();
A comment in CommandObjectTarget.cpp says we're launching the core file:
// Seems weird that we Launch a core file, but that
is
// what we do!
error = process_sp->LoadCore();
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
-Original Message-
From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Jim Ingham
via lldb-dev
Sent: Wednesday, December 02, 2015 12:26 PM
To: Todd Fiala
Cc: LLDB
Subject: Re: [lldb-dev] Linux core dump doesn't show listing when loaded
> On Dec 2, 2015, at 8:35 AM, Todd Fiala via lldb-dev
> wrote:
>
> Does our init file mechanism have the ability to do something conditionally
> if it's a core file? (i.e. do we already have a way to get Ted's desired
> behavior via an inserted call to "thread backtrace all" that somehow gets
> triggered by the init, but only when we're talking about a core file?)
>
> Alternatively, Ted, you could have a wrapper script of some sort (think
> lldb-core.{sh,bat} or something) that you call that sources an lldb
> core-file-specific init file that sets up aliases and the like to start up
> lldb how you want, maybe?
Seems to me, the question is, is "target create --core" the same as "target
create" or is it "target create" followed by "attach". In the latter case, for
"real" processes, we always print the stop state. Since you really are
attaching to the core process when you load a core file, the behavior of
printing the stop state feels more right to me. As to how that prints,
following this logic, that should be the same as any other stop printing, and
is I think orthogonal to Ted's original question.
Jim
>
> On Mon, Nov 30, 2015 at 9:32 AM, Greg Clayton via lldb-dev
> wrote:
> "thread list" should just list the threads and their stop reasons (no
> backtraces). If you want backtraces just do "thread backtrace all".
>
>
> On Nov 24, 2015, at 1:09 PM, Ted Woodward via lldb-dev
> wrote:
> >
> > I’ve been working on an old rev that we’d released on; now I’m much closer
> > to ToT as we move towards our next major Hexagon release.
> >
> > Core dumps on the old rev would print out a listing/disassembly for each
> > thread in the core dump. Now it doesn’t.
> >
> > ToT does this, on x86 Linux:
> >
> > >bin/lldb ~/lldb_test/coredump/lincrash -c ~/lldb_test/coredump/lincore
> > (lldb) target create "/usr2/tedwood/lldb_test/coredump/lincrash" --core
> > "/usr2/tedwood/lldb_test/coredump/lincore"
> > Core file '/usr2/tedwood/lldb_test/coredump/lincore' (x86_64) was loaded.
> > (lldb) thread list
> > Process 0 stopped
> > * thread #1: tid = 0, 0x00401190 lincrash`main + 16 at
> > lincrash.c:5, name = 'lincrash', stop reason = signal SIGSEGV
> > (lldb)
> >
> > I can see the listing by going up and down the stack, but I’d like to see
> > the listing on load. Is the no listing intended?
> >
> > Ted
> >
> > --
> > Qualcomm Innovation Center, Inc.
> > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> > Linux Foundation Collaborative Project
> >
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
>
> --
> -Todd
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Auditing dotest's command line options
I think it's a nice improvement. Passing the options around via the argparse results (as I do in many programs) makes it easier to unit test, but having configuration variables all in a module makes it really simple to find and use everywhere without having them as globals. Thanks for cleaning that up, Zachary! -Todd On Tue, Dec 8, 2015 at 11:31 AM, Greg Clayton via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Sounds good, looks good then. > > > On Dec 8, 2015, at 11:09 AM, Zachary Turner wrote: > > > > One advantage of this approach is that it makes the options available to > the entire test suite. Even if we have no transferring going on, and we > get argparse to return us a perfectly organized structure with everything > in the right format, in order to make all the options accessible to the > rest of the test suite, we still need to stick it in a global module > somewhere. And then you would write > `configuration.options.test_categories`, whereas with this approach we just > write `configuration.test_categories`. It's a minor point, but I like the > shorter member access personally. > > > > On Tue, Dec 8, 2015 at 11:07 AM Zachary Turner > wrote: > > There's no way to avoid doing a transfer out of the options dictionary > at some level, because it's not a straight transfer. There's a ton of > post-processing that gets done on the options dictionary in order to > convert the raw options into a useful format. > > > > That might be solvable with more advanced use of argparse. This > approach does get rid of one level of option transfer though. Because we > would transfer > > 1. From the class returned by argparse into the global > > 2. From the global into the lldb module > > > > Now we only transfer from the argparse class into the `configuration` > module, and everything else just uses that. > > > > > > On Tue, Dec 8, 2015 at 10:52 AM Greg Clayton wrote: > > Do we not want to have an "options" global variable in this module that > contains everything instead of having separate global variables in this > file? The idea would be that you could assign directly when parsing > arguments: > > > > (configuration.options, args) = parser.parse_args(sys.argv[1:]) > > > > Its OK if we don't do this, but this is what I was originally thinking. > Then we don't need to do any transfer out of the options dictionary that is > returned by the option parser. The drawback with this approach is the > "configuration.options" would probably need to be initialized in case > someone tries to access the "configuration.options" without first parsing > arguments. So in that respect the global approach is nicer. > > > > Greg > > > > > On Dec 8, 2015, at 10:45 AM, Zachary Turner > wrote: > > > > > > Hi Greg, > > > > > > Take a look at dotest.py next time you get some free time and let me > know what you think. There should be no more globals. Everything that > used to be a global is now stored in its own module `configuration.py`, and > everything in `configuration.py` can be referenced from everywhere in the > entire test suite. > > > > > > On Fri, Nov 20, 2015 at 10:34 AM Greg Clayton > wrote: > > > Zach, I would also like to get rid of all global variables in the > process of this change. The history goes like this: a long time ago someone > wrote the initial dotest.py and parsed the options manually and stored > results in global variables. Later, someone converted the options over to > use a python library to parse the options, but we mostly copied the options > from the options dictionary over into the globals and still use the globals > all over the code. It would be great if we had at most one global variable > that is something like "g_options" and anyone that was using any global > variables will switch over to use the "g_options." instead. Then we > don't have to make copies and we can let the g_options contain all settings > that are required. > > > > > > > On Nov 18, 2015, at 2:32 PM, Zachary Turner via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > > > > > I would like to do a complete audit of dotest's command line > options, find out who's using what, and then potentially delete anything > that isn't being used. There's a mess of command line options in use, to > the point that it's often hard to find free letters to use for new options. > > > > > > > > I created this spreadsheet with a complete list of command line > options, their descriptions, and a place for people to enter what options > they're using or do not want to be deleted. > > > > > > > > > https://docs.google.com/spreadsheets/d/1wkxAY7l0_cJOHhhsSlh3aKKlQShlX1D7X1Dn8kpqxy4/edit?usp=sharing > > > > > > > > If someone has already written YES in the box that indicates they > need the option, please don't overwrite it. If you write YES in a box, > please provide at least a small rationale for why this option is useful to > you. Feel free to add additional rationale if someone has already added > some rationale. > > > > > > >
