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

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

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 = *nullptr; It's a > reference. > > I might be a good idea to add an overloaded

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 = *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

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 >

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.

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

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

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 >

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

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

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

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

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

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

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

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

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

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

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

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

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*" > >

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

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

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

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,

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

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

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

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

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 >

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

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

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 >

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

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

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

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

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

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,