Re: [lldb-dev] LLDB Evolution - Final Form

Just want to add new things as I think of them. On Mon, Sep 19, 2016 at 1:18 PM Zachary Turner wrote: > > >1. > >lldb-cli -- lldb interactive command line. > > A great way to test this would be have a tool as mentioned, and you pass an lldb command to the tool. It parses it and spits ou

Re: [lldb-dev] LLDB Evolution - Final Form

I am a bit late to the party, but anyways, here are my thoughts on the issues here: On 19 September 2016 at 21:18, Zachary Turner via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Difficulty / Effort: 3 (5 if we have to add enhanced mode support) > > Use llvm streams instead of lldb::StreamString >

Re: [lldb-dev] LLDB Evolution - Final Form

The =delete overload of StringRef is also a great idea. It just helped me catch all the places where we were initializing global option tables from const char *s On Wed, Sep 21, 2016 at 2:28 PM Zachary Turner wrote: > On Wed, Sep 21, 2016 at 2:20 PM Greg Clayton wrote: > > > > On Sep 21, 2016,

Re: [lldb-dev] LLDB Evolution - Final Form

On Wed, Sep 21, 2016 at 2:20 PM Greg Clayton wrote: > > > On Sep 21, 2016, at 1:55 PM, Zachary Turner wrote: > > > > :-/ The same thing happens if you write Foo &f = *nullptr; It's a > reference. > > I might be a good idea to add an overloaded constructor for nullptr and > void * and delete t

Re: [lldb-dev] LLDB Evolution - Final Form

> On Sep 21, 2016, at 1:55 PM, Zachary Turner wrote: > > :-/ The same thing happens if you write Foo &f = *nullptr; It's a > reference. I might be a good idea to add an overloaded constructor for nullptr and void * and delete them so that we can't implicitly create a StringRef from nullptr

Re: [lldb-dev] LLDB Evolution - Final Form

:-/ The same thing happens if you write Foo &f = *nullptr; It's a reference. Did you try StringRef::withNullAsEmpty()? BTW what code are you converting? I'm working on some of the options code as we speak. On Wed, Sep 21, 2016 at 1:43 PM Greg Clayton wrote: > I am laughing as I convert cod

Re: [lldb-dev] LLDB Evolution - Final Form

I am laughing as I convert code over to using StringRef and I get crashes: if (name == NULL) StringRef is nice enough to implicitly construct a StringRef from NULL or nullptr so that it can crash for me... > On Sep 21, 2016, at 11:09 AM, Zachary Turner via lldb-dev > wrote: > > Adding anothe

Re: [lldb-dev] LLDB Evolution - Final Form

the variable used to be a "const char *" in the last example... > On Sep 21, 2016, at 1:43 PM, Greg Clayton wrote: > > I am laughing as I convert code over to using StringRef and I get crashes: > > if (name == NULL) > > StringRef is nice enough to implicitly construct a StringRef from NULL or

Re: [lldb-dev] LLDB Evolution - Final Form

Adding another thing to my list (thanks to Mehdi and Eric Christopher for the idea). Apply libfuzzer to LLDB. Details sparse on what parse of LLDB and how, but I think it would be easy to come up with candidates. On Mon, Sep 19, 2016 at 1:18 PM Zachary Turner wrote: > Following up with Kate's

Re: [lldb-dev] LLDB Evolution - Final Form

I agree that for case #1, we must handle that by checking the pointer. Same thing for #2. For #3 we just need to fix the bug in clang. Our case in more of a different issue. The cause of most crashes for us is in the clang::ASTContext class as we try to create types from DWARF. clang::ASTContex

Re: [lldb-dev] LLDB Evolution - Final Form

BTW, one more comment about this. If you've got a situation where LLDB is using LLVM in a way that makes LLDB crash, there are 3 possibilities: 1) LLVM / Clang is vending a pointer and we're supposed to be checking it for null. 2) We used the LLVM / Clang API incorrectly causing it to return us a

Re: [lldb-dev] LLDB Evolution - Final Form

On Tue, Sep 20, 2016 at 2:51 PM Greg Clayton wrote: > > > On Sep 20, 2016, at 2:49 PM, Mehdi Amini wrote: > > > > > >> On Sep 20, 2016, at 2:46 PM, Zachary Turner wrote: > >> > >> Occasionally (and in my experience *very* occasionally), you need to > treat "" as different from null. > > doesn't

Re: [lldb-dev] LLDB Evolution - Final Form

> On Sep 20, 2016, at 2:41 PM, Mehdi Amini wrote: > >> >> On Sep 20, 2016, at 2:31 PM, Greg Clayton wrote: >> >> We should avoid crashing if there is a reasonable work around when the input >> is bad. StringRef with NULL is easy, just put NULL and zero length and don't >> crash. Just becaus

Re: [lldb-dev] LLDB Evolution - Final Form

> On Sep 20, 2016, at 2:49 PM, Mehdi Amini wrote: > > >> On Sep 20, 2016, at 2:46 PM, Zachary Turner wrote: >> >> Occasionally (and in my experience *very* occasionally), you need to treat >> "" as different from null. doesn't StringRef store an actual pointer to ""? This would mean String

Re: [lldb-dev] LLDB Evolution - Final Form

> On Sep 20, 2016, at 2:46 PM, Zachary Turner wrote: > > Occasionally (and in my experience *very* occasionally), you need to treat "" > as different from null. return an Optional? — Mehdi > But the frequency with which that is really necessary is much lower than > people realize. It

Re: [lldb-dev] LLDB Evolution - Final Form

Occasionally (and in my experience *very* occasionally), you need to treat "" as different from null. But the frequency with which that is really necessary is much lower than people realize. It just seems high because of the prevalence of raw pointers. For every other case, you can use withNullA

Re: [lldb-dev] LLDB Evolution - Final Form

> On Sep 20, 2016, at 2:31 PM, Greg Clayton wrote: > > We should avoid crashing if there is a reasonable work around when the input > is bad. StringRef with NULL is easy, just put NULL and zero length and don't > crash. Just because it is documented, doesn't mean it needs to stay that way, >

Re: [lldb-dev] LLDB Evolution - Final Form

Also, maybe that code could just return a StringRef. It's like I mentioned a few days ago (don't remember if it was this thread or another), but when you've got StringRefs all the way down, this problem pretty much disappears. On Tue, Sep 20, 2016 at 2:36 PM Zachary Turner wrote: > StringRef ha

Re: [lldb-dev] LLDB Evolution - Final Form

StringRef has `withNullAsEmpty` which I added a few days ago. It will return an empty StringRef. seems to me that should solve most of those kinds of problems. On Tue, Sep 20, 2016 at 2:31 PM Greg Clayton wrote: > We should avoid crashing if there is a reasonable work around when the > input i

Re: [lldb-dev] LLDB Evolution - Final Form

We should avoid crashing if there is a reasonable work around when the input is bad. StringRef with NULL is easy, just put NULL and zero length and don't crash. Just because it is documented, doesn't mean it needs to stay that way, but I am not going to fight that battle. We should make every e

Re: [lldb-dev] LLDB Evolution - Final Form

> On Sep 20, 2016, at 2:19 PM, Greg Clayton wrote: > > Again, strlen is a stupid example as it is well documented. All of llvm and > clang are not. IMO that is: 1) A free claim that is easily defeated (to prove you wrong on *all* of LLVM being not document I just have to point you to one exa

Re: [lldb-dev] LLDB Evolution - Final Form

On 20 September 2016 at 17:25, Greg Clayton wrote: > > Well the DWARF code was copied from LLDB into LLVM. The original person > didn't update LLDB to use it, so things diverged. Yeah, sorry I didn't mention that explicitly. I do recall someone pointed that out when this came up previously. > I

Re: [lldb-dev] LLDB Evolution - Final Form

I don't think anyone is ok with that. I just think that a better solution is to document them. Why handle at runtime what is known about at compile time? On Tue, Sep 20, 2016 at 2:24 PM Zachary Turner wrote: > Well, but StringRef for example is well documented. So it seems to me > like there'

Re: [lldb-dev] LLDB Evolution - Final Form

> On Sep 20, 2016, at 2:21 PM, Ed Maste via lldb-dev > wrote: > > On 19 September 2016 at 16:18, Zachary Turner via lldb-dev > wrote: >> >> De-inventing the wheel - We should use more code from LLVM, and delete code >> in LLDB where LLVM provides a solution. > > Another example of duplicated

Re: [lldb-dev] LLDB Evolution - Final Form

Well, but StringRef for example is well documented. So it seems to me like there's an example of a perfectly used assert. It's documented that you can't use null, and if you do it asserts. Just like strlen. The issue I have with "you can't ever assert" is that it brings it into an absolute when

Re: [lldb-dev] LLDB Evolution - Final Form

A better solution would be to return an error indicating what went wrong with llvm::Error. I really can't believe people are ok with "well you called me with the wrong parameters that aren't documented, I am unhappy and will crash your program" mentality. > On Sep 20, 2016, at 2:11 PM, Adria

Re: [lldb-dev] LLDB Evolution - Final Form

On 19 September 2016 at 16:18, Zachary Turner via lldb-dev wrote: > > De-inventing the wheel - We should use more code from LLVM, and delete code > in LLDB where LLVM provides a solution. Another example of duplicated code is the debug info parsing (LLDB source/Plugins/SymbolFile/DWARF vs LLVM li

Re: [lldb-dev] LLDB Evolution - Final Form

Again, strlen is a stupid example as it is well documented. All of llvm and clang are not. > On Sep 20, 2016, at 1:59 PM, Zachary Turner wrote: > > > > On Tue, Sep 20, 2016 at 1:55 PM Greg Clayton wrote: > > > On Sep 20, 2016, at 1:45 PM, Zachary Turner wrote: > > > > I do agree that assert

Re: [lldb-dev] LLDB Evolution - Final Form

My concern about this example: void do_something(foo *p) { assert(p); if (p) p->crash(); } Is that by skipping the operation when the pointer is null is that it's not clear what it should do if it's precondition isn't met. Sure, it won't crash, but it's also not going to "do some

Re: [lldb-dev] LLDB Evolution - Final Form

On Tue, Sep 20, 2016 at 1:55 PM Greg Clayton wrote: > > > On Sep 20, 2016, at 1:45 PM, Zachary Turner wrote: > > > > I do agree that asserts are sometimes used improperly. But who's to say > that the bug was the assert, and not the surrounding code? For example, > consider this code: > > > > a

Re: [lldb-dev] LLDB Evolution - Final Form

My 2¢: > assert(p); > int x = *p; > … > assert(ptr); > int x = strlen(ptr); Both of these should either check for null, be in a situation where p is obviously good (e.g., p is data() from a stack-allocated std::vector), or use references. The assertion to my mind is like an admission "I'm not

Re: [lldb-dev] LLDB Evolution - Final Form

> On Sep 20, 2016, at 1:45 PM, Zachary Turner wrote: > > I do agree that asserts are sometimes used improperly. But who's to say that > the bug was the assert, and not the surrounding code? For example, consider > this code: > > assert(p); > int x = *p; Should be written as: assert(p); if

Re: [lldb-dev] LLDB Evolution - Final Form

I do agree that asserts are sometimes used improperly. But who's to say that the bug was the assert, and not the surrounding code? For example, consider this code: assert(p); int x = *p; Should this assert also not be here in library code? I mean it's obvious that the program is about to crash

Re: [lldb-dev] LLDB Evolution - Final Form

On Tue, Sep 20, 2016 at 4:37 PM, Ted Woodward via lldb-dev < lldb-dev@lists.llvm.org> wrote: > > From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of > Zachary Turner via lldb-dev > Sent: Tuesday, September 20, 2016 12:47 PM > > > This kind of philisophical debate is probably worth

Re: [lldb-dev] LLDB Evolution - Final Form

From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Zachary Turner via lldb-dev Sent: Tuesday, September 20, 2016 12:47 PM > This kind of philisophical debate is probably worthy of a separate thread :) > That being said, I think asserts are typically used in places where the

Re: [lldb-dev] LLDB Evolution - Final Form

> On Sep 20, 2016, at 10:47 AM, Mehdi Amini wrote: > >> >> On Sep 20, 2016, at 10:33 AM, Greg Clayton wrote: >> >>> >>> On Sep 19, 2016, at 2:46 PM, Mehdi Amini wrote: >>> On Sep 19, 2016, at 2:34 PM, Greg Clayton wrote: > > On Sep 19, 2016, at 2:20 PM, Mehdi Ami

Re: [lldb-dev] LLDB Evolution - Final Form

> On Sep 20, 2016, at 10:46 AM, Zachary Turner wrote: > > This kind of philisophical debate is probably worthy of a separate thread :) > That being said, I think asserts are typically used in places where the > assert firing means "You're going to crash *anyway*" > > It's like trying to hand

Re: [lldb-dev] LLDB Evolution - Final Form

> On Sep 20, 2016, at 10:33 AM, Greg Clayton wrote: > >> >> On Sep 19, 2016, at 2:46 PM, Mehdi Amini wrote: >> >>> >>> On Sep 19, 2016, at 2:34 PM, Greg Clayton wrote: >>> On Sep 19, 2016, at 2:20 PM, Mehdi Amini wrote: > > On Sep 19, 2016, at 2:02 PM, Greg Clayt

Re: [lldb-dev] LLDB Evolution - Final Form

This kind of philisophical debate is probably worthy of a separate thread :) That being said, I think asserts are typically used in places where the assert firing means "You're going to crash *anyway*" It's like trying to handle a bad alloc. What are you going to do anyway? You can crash now or

Re: [lldb-dev] LLDB Evolution - Final Form

> On Sep 19, 2016, at 2:46 PM, Mehdi Amini wrote: > >> >> On Sep 19, 2016, at 2:34 PM, Greg Clayton wrote: >> >>> >>> On Sep 19, 2016, at 2:20 PM, Mehdi Amini wrote: >>> On Sep 19, 2016, at 2:02 PM, Greg Clayton via lldb-dev wrote: > On Sep 19, 2016, at 1:

Re: [lldb-dev] LLDB Evolution - Final Form

FWIW I added a function to StringRef the other day that looks like this: static StringRef withNullAsEmpty(const char *Str) { return StringRef(Str ? Str : ""); } I've been using this code in converting existing uses of const char * over to StringRef. It's not 100% what you want, but at least it

Re: [lldb-dev] LLDB Evolution - Final Form

But StringRef is a smart string wrapper and it is there for exactly this reason: to make string handling correct. So let us let it be smart and not crash if you make it with null and call .size() on it... > On Sep 19, 2016, at 2:37 PM, Zachary Turner wrote: > > FWIW, strlen(nullptr) will also c

Re: [lldb-dev] LLDB Evolution - Final Form

BTW, another way to achieve this worthy goal is to require that all the lldb command-line commands be written using the C++ Version of the SB API's. It should be its own module, and the driver should link to that, not directly to the LLDB.framework at all. That would also force us to provide a

Re: [lldb-dev] LLDB Evolution - Final Form

> On Sep 19, 2016, at 3:32 PM, Zachary Turner wrote: > > Ok, in that case I agree with you more. We should test the scripting > interface. It's part of the software, it should be treated as such. 100% on > board. But if we find that it is lacking (or even just inconvenient) to test > the

Re: [lldb-dev] LLDB Evolution - Final Form

Ok, in that case I agree with you more. We should test the scripting interface. It's part of the software, it should be treated as such. 100% on board. But if we find that it is lacking (or even just inconvenient) to test the full capabilities of the debugger, we shouldn't force it to. All of

Re: [lldb-dev] LLDB Evolution - Final Form

Obviously I defer to you on whether testing via the SB API is better than what GDB does or used to do. But these are not the only two systems in the world. Having used both LLDB and LLVM's test suite extensively, I still remain unconvinced that LLDB's testing situation could not be improved. Do

Re: [lldb-dev] LLDB Evolution - Final Form

> On Sep 19, 2016, at 3:19 PM, Zachary Turner wrote: > > Obviously I defer to you on whether testing via the SB API is better than > what GDB does or used to do. But these are not the only two systems in the > world. Having used both LLDB and LLVM's test suite extensively, I still > remain

Re: [lldb-dev] LLDB Evolution - Final Form

> On Sep 19, 2016, at 2:11 PM, Zachary Turner via lldb-dev > wrote: > > > > On Mon, Sep 19, 2016 at 2:02 PM Greg Clayton wrote: > > > • Separate testing tools > > • One question that remains open is how to represent > > the complicated needs of a debugge

Re: [lldb-dev] LLDB Evolution - Final Form

> On Sep 19, 2016, at 2:34 PM, Greg Clayton wrote: > >> >> On Sep 19, 2016, at 2:20 PM, Mehdi Amini wrote: >> >>> >>> On Sep 19, 2016, at 2:02 PM, Greg Clayton via lldb-dev >>> wrote: >>> >>> On Sep 19, 2016, at 1:18 PM, Zachary Turner via lldb-dev wrote: Following

Re: [lldb-dev] LLDB Evolution - Final Form

On Mon, Sep 19, 2016 at 2:37 PM Greg Clayton wrote: > > > Just thinking out loud here, but one possibility is to have multiple > pools. One which is ref counted and one which isn't. If you need > something to live forever, vend it from the non-ref-counted pool. > Otherwise vend it from the ref

Re: [lldb-dev] LLDB Evolution - Final Form

> On Sep 19, 2016, at 2:31 PM, Zachary Turner via lldb-dev > wrote: > > > > On Mon, Sep 19, 2016 at 2:20 PM Mehdi Amini > wrote: > > > I’m surprise by your aversion to assertions, what is your suggested > alternative? Are you expecting to check and handle eve

Re: [lldb-dev] LLDB Evolution - Final Form

FWIW, strlen(nullptr) will also crash just as easily as StringRef(nullptr) will crash, so that one isn't a particularly convincing example of poorly used asserts, since the onus on the developer is exactly the same as with strlen. That said, I still know where you're coming from :) On Mon, Sep 19

Re: [lldb-dev] LLDB Evolution - Final Form

> On Sep 19, 2016, at 2:24 PM, Zachary Turner wrote: > > > > On Mon, Sep 19, 2016 at 2:02 PM Greg Clayton wrote: > > > On Sep 19, 2016, at 1:18 PM, Zachary Turner via lldb-dev > > wrote: > > > > Following up with Kate's post from a few weeks ago, I think the dust has > > settled on the co

Re: [lldb-dev] LLDB Evolution - Final Form

> On Sep 19, 2016, at 2:20 PM, Mehdi Amini wrote: > >> >> On Sep 19, 2016, at 2:02 PM, Greg Clayton via lldb-dev >> wrote: >> >> >>> On Sep 19, 2016, at 1:18 PM, Zachary Turner via lldb-dev >>> wrote: >>> >>> Following up with Kate's post from a few weeks ago, I think the dust has >>> s

Re: [lldb-dev] LLDB Evolution - Final Form

On Mon, Sep 19, 2016 at 2:20 PM Mehdi Amini wrote: > > > I’m surprise by your aversion to assertions, what is your suggested > alternative? Are you expecting to check and handle every possible > invariants everywhere and recover (or signal an error) properly? That does > not seem practical, and i

Re: [lldb-dev] LLDB Evolution - Final Form

> On Sep 19, 2016, at 2:11 PM, Zachary Turner wrote: > > > > On Mon, Sep 19, 2016 at 2:02 PM Greg Clayton wrote: > > > • Separate testing tools > > • One question that remains open is how to represent > > the complicated needs of a debugger in lit tests.

Re: [lldb-dev] LLDB Evolution - Final Form

On Mon, Sep 19, 2016 at 2:02 PM Greg Clayton wrote: > > > On Sep 19, 2016, at 1:18 PM, Zachary Turner via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > Following up with Kate's post from a few weeks ago, I think the dust has > settled on the code reformat and it went over pretty smoothly f

Re: [lldb-dev] LLDB Evolution - Final Form

> On Sep 19, 2016, at 2:02 PM, Greg Clayton via lldb-dev > wrote: > > >> On Sep 19, 2016, at 1:18 PM, Zachary Turner via lldb-dev >> wrote: >> >> Following up with Kate's post from a few weeks ago, I think the dust has >> settled on the code reformat and it went over pretty smoothly for th

Re: [lldb-dev] LLDB Evolution - Final Form

On Mon, Sep 19, 2016 at 2:02 PM Greg Clayton wrote: > > > • Separate testing tools > > • One question that remains open is how to > represent the complicated needs of a debugger in lit tests. Part a) above > covers the trivial cases, but what about the difficu

Re: [lldb-dev] LLDB Evolution - Final Form

On Mon, Sep 19, 2016 at 1:57 PM Enrico Granata wrote: > > I am definitely not innocent in this regard. However, it does happen for a > reason. > > Sometimes, I am writing code in lldb that is the foundation of something I > need to do over on the Swift.org side. > > I'll lay out foundational work

Re: [lldb-dev] LLDB Evolution - Final Form

> On Sep 19, 2016, at 1:18 PM, Zachary Turner via lldb-dev > wrote: > > Following up with Kate's post from a few weeks ago, I think the dust has > settled on the code reformat and it went over pretty smoothly for the most > part. So I thought it might be worth throwing out some ideas for whe

Re: [lldb-dev] LLDB Evolution - Final Form

A few remarks > On Sep 19, 2016, at 1:18 PM, Zachary Turner via lldb-dev > wrote: > > Following up with Kate's post from a few weeks ago, I think the dust has > settled on the code reformat and it went over pretty smoothly for the most > part. So I thought it might be worth throwing out some

Re: [lldb-dev] LLDB Evolution - Final Form

On Mon, Sep 19, 2016 at 1:38 PM Sean Callanan wrote: > I'll only comment on the stuff that affects me. > > >1. Use llvm streams instead of lldb::StreamString > 1. Supports output re-targeting (stderr, stdout, std::string, etc), > printf style formatting, and type-safe streaming

Re: [lldb-dev] LLDB Evolution - Final Form

I'll only comment on the stuff that affects me. > Use llvm streams instead of lldb::StreamString > Supports output re-targeting (stderr, stdout, std::string, etc), printf style > formatting, and type-safe streaming operators. > Interoperates nicely with many existing llvm utility classes > Risk:

[lldb-dev] LLDB Evolution - Final Form

Following up with Kate's post from a few weeks ago, I think the dust has settled on the code reformat and it went over pretty smoothly for the most part. So I thought it might be worth throwing out some ideas for where we go from here. I have a large list of ideas (more ideas than time, sadly) th