Re: [lldb-dev] Unifying ctor+Clear() inits into in-class initializers?

[Leonard Mosescu via lldb-dev]

>
> void Clear() {
>   this->~ClassName();
>   new (this) ClassName();
> }


My 2c: this is clever, but not without downsides:
1. It may do more than intended (it will destroy all members / bases)
2. It forces construction and 'reset' to be exactly the same, which is not
always desirable
3. Most importantly if you really want a freshly initialized object, just
do that (create a new object)

I like in-class initializers, but for clear/reset operations I prefer a
standalone operation. And as Pavel suggested, calling 'clear' from the
constructor is a good way to factor out commonality.



On Sun, Nov 19, 2017 at 6:58 AM, Jan Kratochvil via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Hi,
>
> https://reviews.llvm.org/D40212
>
> At least DWARFCompileUnit and I see even for example MachVMRegion duplicate
> intialization of fields in both their constructor and Clear().  Moreover
> the
> initialization is in different place than declaration of the member
> variable.
>
> Is it OK to just use in-class member variable initializers and:
> void Clear() {
>   this->~ClassName();
>   new (this) ClassName();
> }
> ?
>
> Pavel Labath otherwise suggests to just call Clear() from the constructor.
> Still then I find the code could be more readable with in-class members
> initializers - moreover during further refactorizations+extensions.
>
>
> Thanks,
> Jan Kratochvil
> ___
> 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] Unifying ctor+Clear() inits into in-class initializers?

[Zachary Turner via lldb-dev]

+1, this pattern looks like asking for UB
On Mon, Nov 20, 2017 at 11:57 AM Leonard Mosescu via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> void Clear() {
>>   this->~ClassName();
>>   new (this) ClassName();
>> }
>
>
> My 2c: this is clever, but not without downsides:
> 1. It may do more than intended (it will destroy all members / bases)
> 2. It forces construction and 'reset' to be exactly the same, which is not
> always desirable
> 3. Most importantly if you really want a freshly initialized object, just
> do that (create a new object)
>
> I like in-class initializers, but for clear/reset operations I prefer a
> standalone operation. And as Pavel suggested, calling 'clear' from the
> constructor is a good way to factor out commonality.
>
>
>
> On Sun, Nov 19, 2017 at 6:58 AM, Jan Kratochvil via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> Hi,
>>
>> https://reviews.llvm.org/D40212
>>
>> At least DWARFCompileUnit and I see even for example MachVMRegion
>> duplicate
>> intialization of fields in both their constructor and Clear().  Moreover
>> the
>> initialization is in different place than declaration of the member
>> variable.
>>
>> Is it OK to just use in-class member variable initializers and:
>> void Clear() {
>>   this->~ClassName();
>>   new (this) ClassName();
>> }
>> ?
>>
>> Pavel Labath otherwise suggests to just call Clear() from the constructor.
>> Still then I find the code could be more readable with in-class members
>> initializers - moreover during further refactorizations+extensions.
>>
>>
>> Thanks,
>> Jan Kratochvil
>> ___
>> 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] negative in stop reason

[Jim Ingham via lldb-dev]

The breakpoint hit count is not increasing, which makes  it look like we aren’t 
managing to do the job of stepping past the breakpoint.  That requires 
restoring the breakpoint instruction, setting the processor to single-step, 
running just the thread that hit the breakpoint, then reinserting the trap.

I can’t see from the info you gave why this might be happening.

You can get lldb to dump the log of its stepping operations by running the 
command:

(lldb) log enable -f /tmp/lldb-step-log.txt

then step, then you can look at the log to see what happened.  You might find 
this log confusing if you don’t know how lldb works but if you file a bug with 
the llvm.org bugreporter (bugs.llvm.org) and include this log, the output you 
listed below and the disassembly of the function you are trying to step past, I 
will take a look. 

Jim

> On Nov 17, 2017, at 8:10 PM, Jian Liu/Gmail  wrote:
> 
> 
> 
> 2017-11-18 3:49 GMT+08:00 Jim Ingham  >:
> Negative breakpoint ID’s are used for breakpoints lldb sets for internal 
> purposes. You can see the internal breakpoints with the “break list -i” 
> command.
> 
> “continue” doesn’t usually need to set internal breakpoints, however.  And we 
> don’t usually tell you about internal breakpoint hits, especially if you hit 
> a user breakpoint at the same time.  So that is a little curious.  But I also 
> wonder if you are hitting this breakpoint over and over? 
> 
> Hi Jim, Thanks for your reply. Yes, I have hit the breakpoint over and over. 
> 
> I replay the same debugging process again today. This time, the break point 
> is set as breakpoint 2 (not breakpoint 3 in my early email). When I input 
> "break list 2.1“, lldb shows:
> 
> (lldb) br list 2.1
> 2: file = 'Executor.cpp', line = 3222, exact_match = 0, locations = 1, 
> resolved = 1, hit count = 1
>   2.1: where = 
> klee`klee::Executor::executeMemoryOperation(klee::ExecutionState&, bool, 
> klee::ref, klee::ref, klee::KInstruction*) + 39 at 
> Executor.cpp:3228, address = 0x00547807, resolved, hit count = 1 
> 
> When I use "continue" to let the program to go on, lld shows:
> 
> (lldb) br list 2.1
> 2: file = 'Executor.cpp', line = 3222, exact_match = 0, locations = 1, 
> resolved = 1, hit count = 1
>   2.1: where = 
> klee`klee::Executor::executeMemoryOperation(klee::ExecutionState&, bool, 
> klee::ref, klee::ref, klee::KInstruction*) + 39 at 
> Executor.cpp:3228, address = 0x00547807, resolved, hit count = 1 
> 
> (lldb) n
> Process 6706 stopped
> * thread #1, name = 'klee', stop reason = breakpoint 2.1 -4.1
> frame #0: 
> klee`klee::Executor::executeMemoryOperation(this=0x01278800, 
> state=0x0132d710, isWrite=true, address=ref @ 
> 0x7fffd480, value=ref @ 0x7fffd4b0, 
> target=0x) at Executor.cpp:3228
>3225 ref value /* undef 
> if read */,
>3226 KInstruction *target /* 
> undef if write */) {
>3227 Expr::Width type = (isWrite ? value->getWidth() : 
> -> 3228
> getWidthForLLVMType(target->inst->getType()));
>3229 unsigned bytes = Expr::getMinBytesForWidth(type);
>3230 std::string name = "node";
>3231 if (SimplifySymIndices) {
> (lldb) 
> 
> Obviously, the program do NOT go on. As you said, internal breakpoints were 
> hit, because of a negative number "-4.1" in stop reason. When I input 
> "continue" again, it shows.
> 
> (lldb) n
> Process 6706 stopped
> * thread #1, name = 'klee', stop reason = breakpoint 2.1 -6.1
> frame #0: 
> klee`klee::Executor::executeMemoryOperation(this=0x01278800, 
> state=0x0132d710, isWrite=true, address=ref @ 
> 0x7fffd480, value=ref @ 0x7fffd4b0, 
> target=0x) at Executor.cpp:3228
>3225 ref value /* undef 
> if read */,
>3226 KInstruction *target /* 
> undef if write */) {
>3227 Expr::Width type = (isWrite ? value->getWidth() : 
> -> 3228
> getWidthForLLVMType(target->inst->getType()));
>3229 unsigned bytes = Expr::getMinBytesForWidth(type);
>3230 std::string name = "node";
>3231 if (SimplifySymIndices) {
> 
> The negative number in stop reason becomes to "-6.1". When I query internal 
> breakpoints with the “break list -i” command, it shows.
> 
> (lldb) break list -i
> Current breakpoints:
> Kind: shared-library-event
> -1: address = klee[0x005361a0], locations = 1 Options: disabled 
> one-shot 
> 
>   -1.1: where = klee`_start, address = 0x005361a0, unresolved, hit 
> count = 1 
> 
> Kind: shared-library-event
> -2: address = ld-linux-x86-64.so.2[0x00011060], locations = 1, 
> resolved = 1, hit count = 0
> 
>   -2.1: where = ld-linux-x86-64.so.2`_dl_debug_state, address =