Re: [lldb-dev] Symbol Server for everyone.

[Taras Tsugrii via lldb-dev]

Thank you Jim! Sounds like this should work!

On 8/30/16, 8:45 AM, "jing...@apple.com on behalf of Jim Ingham" 
 wrote:

The "dsymForUUID" tool doesn't handle copying source files around - we tend 
to just remote mount them.  But we do include these keys in the return plist so 
that lldb can automatically remap the source files from where they were at 
build time to where they are at debug time.  So if your symbol server copies 
files locally and they aren't in the same location as at build time, you might 
want to play a similar trick on your end.

Jim

> On Aug 30, 2016, at 7:18 AM, Taras Tsugrii via lldb-dev 
 wrote:
> 
> DBGBuildSourcePath
> /path/to/build/sources
> DBGSourcePath
> /path/to/actual/sources



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

[lldb-dev] Not able to set breakpoints above line #70 in lldb-mi.

[Michael Kuklinski via lldb-dev]

Hello,

 

I'm having an issue setting breakpoints using lldb-mi.

 

I am trying to run a C++ program (which is itself a brainfsck interpreter),
compiled for MIPS32r6 using Clang, linked with lld, and am trying to use
lldb-mi as the debugger. I am using lldb-mi as my primary use for it is as
an intermediary for a visual debugger, but I get the same behavior when
using it myself.

 

Whenever I try to set a reasonable breakpoint at or below line #70 in
Main.cpp, it works - it is resolved, it sends a Z0 packet to the gdb stub,
and it works. However, when I attempt to set any breakpoint above line #70,
it comes up as 'unresolved' (though the addresses shown in the list seem
reasonable) and does not submit anything to the stub as a result.

 

When I dumped the line table using both readelf and lldb, they were
completely reasonable - almost every line until the end had an entry - there
was no cut off at line #70.

 

At this point, I'm unsure if I'm doing something wrong, or if lldb-mi is
having some difficulty with my MIPS binary. 

 

I'm building with the following options:



clang -std=c++14 -mcompact-branches=always -fasynchronous-unwind-tables
-funwind-tables -fexceptions -fcxx-exceptions -mips32r6 -O0 -g -glldb ...

 

lld --discard-none -znorelro --eh-frame-hdr ...

 

And the resultant binary is here:
http://filebin.ca/2tJzo2LLBJWO/MipsTest.bin (if you wish something to
analyze).

 

I've also uploaded the rather poor code for Main.cpp here:
https://paste.ee/p/WYs8Y

 

I've also tested this on a second source file in the ELF ('Recoder.cpp')
which stops working at a lower line number, but has similar behavior -
there's a hard cut-off where lldb stops working with breakpoints. The line
table for that file also seems fine.

 

Just for example, when I set a breakpoint at or below 70 (note, I get the
same behavior when not specifying -H):

 

break set -H -f Main.cpp -l 70

(gdb)

=breakpoint-created,bkpt={number="1",type="breakpoint",disp="keep",enabled="
y",addr="0x00013488",func="main",file="Main.cpp",fullname="D:\Proj

ects\MipsTest2\MipsTest/Main.cpp",line="70",times="0",original-location="Mai
n.cpp:70"}

(gdb)

=breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",enabled=
"y",addr="0x00013488",func="main",file="Main.cpp",fullname="D:\Pro

jects\MipsTest2\MipsTest/Main.cpp",line="70",times="0",original-location="Ma
in.cpp:70"}

 

And this is what I see when I set a breakpoint after 70:



break set -H -f Main.cpp -l 72

(gdb)

=breakpoint-created,bkpt={number="2",type="breakpoint",disp="keep",enabled="
y",addr="0x000134a0",func="main",file="Main.cpp",fullname="D:\Proj

ects\MipsTest2\MipsTest/Main.cpp",line="72",times="0",original-location="Mai
n.cpp:72"}

 

However, the list looks as such:

 

break list

Current breakpoints:

1: file = 'Main.cpp', line = 70, exact_match = 0, locations = 1, resolved =
1, hit count = 1

  1.1: where = MipsTest.bin`main + 520 at Main.cpp:70, address = 0x00013488,
resolved, hit count = 1

 

2: file = 'Main.cpp', line = 72, exact_match = 0, locations = 1

  2.1: where = MipsTest.bin`main + 544 at Main.cpp:72, address =
MipsTest.bin[0x000134a0], unresolved, hit count = 0



Note that the address seems completely reasonable but it remains unresolved,
and does not submit anything to the stub.

 

Thanks for any help or insight you might be able to provide,

Michael

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

Re: [lldb-dev] Not able to set breakpoints above line #70 in lldb-mi.

[Michael Kuklinski via lldb-dev]

This is my output from that:

https://paste.ee/p/iGKZr

Though I am admittedly unsure what I am looking for.

Michael

-Original Message-
From: jing...@apple.com [mailto:jing...@apple.com] 
Sent: Tuesday, August 30, 2016 2:40 PM
To: Michael Kuklinski 
Cc: Greg Clayton ; lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] Not able to set breakpoints above line #70 in lldb-mi.

The addresses for the two breakpoints are reported differently in your "break 
list" output.  The successful one is given as:

0x00013488

but the one that isn't sent is still given as:

MipsTest.bin[0x000134a0]

That's a file offset address, not a load address.  It sounds like we don't know 
where the section that contains the second address got loaded in memory.  In 
your binary they are all in the same text section, so I'm not sure how this 
would happen.  

Once you are running, try:

(lldb) image dump sections MipsTest.bin

and see if there's anything funny going on there.

Jim

> On Aug 30, 2016, at 11:11 AM, Michael Kuklinski via lldb-dev 
>  wrote:
> 
> Those are the same results I get - however, when actually attached to the 
> remote target, line 70 sends a Z0 packet, whereas line 72 sends absolutely 
> nothing, regardless of the order.
> 
> I am on LLDB revision 279920, and LLVM revision 279925.
> 
> Michael
> 
> -Original Message-
> From: Greg Clayton [mailto:gclay...@apple.com]
> Sent: Tuesday, August 30, 2016 10:41 AM
> To: Michael Kuklinski 
> Cc: lldb-dev@lists.llvm.org
> Subject: Re: [lldb-dev] Not able to set breakpoints above line #70 in lldb-mi.
> 
> Seems to work for me just fine with your binary:
> 
> lldb /Volumes/work/gclayton/Downloads/MipsTest.bin
> (lldb) target create "/Volumes/work/gclayton/Downloads/MipsTest.bin"
> Current executable set to '/Volumes/work/gclayton/Downloads/MipsTest.bin' 
> (mipsr6el).
> (lldb) break set -H -f Main.cpp -l 70
> Breakpoint 1: where = MipsTest.bin`main + 520 at Main.cpp:70, address 
> = 0x00013488
> (lldb) break set -H -f Main.cpp -l 72
> Breakpoint 2: where = MipsTest.bin`main + 544 at Main.cpp:72, address 
> = 0x000134a0
> (lldb) b
> Current breakpoints:
> 1: file = 'Main.cpp', line = 70, exact_match = 0, locations = 1
>  1.1: where = MipsTest.bin`main + 520 at Main.cpp:70, address = 
> MipsTest.bin[0x00013488], unresolved, hit count = 0
> 
> 2: file = 'Main.cpp', line = 72, exact_match = 0, locations = 1
>  2.1: where = MipsTest.bin`main + 544 at Main.cpp:72, address = 
> MipsTest.bin[0x000134a0], unresolved, hit count = 0
> 
> You don't need to use lldb-mi to reproduce this. Command line LLDB should 
> give you the same results.
> 
> What version of LLDB are you using?
> 
>> On Aug 30, 2016, at 2:45 AM, Michael Kuklinski via lldb-dev 
>>  wrote:
>> 
>> Hello,
>> 
>> I’m having an issue setting breakpoints using lldb-mi.
>> 
>> I am trying to run a C++ program (which is itself a brainfsck interpreter), 
>> compiled for MIPS32r6 using Clang, linked with lld, and am trying to use 
>> lldb-mi as the debugger. I am using lldb-mi as my primary use for it is as 
>> an intermediary for a visual debugger, but I get the same behavior when 
>> using it myself.
>> 
>> Whenever I try to set a reasonable breakpoint at or below line #70 in 
>> Main.cpp, it works – it is resolved, it sends a Z0 packet to the gdb stub, 
>> and it works. However, when I attempt to set any breakpoint above line #70, 
>> it comes up as ‘unresolved’ (though the addresses shown in the list seem 
>> reasonable) and does not submit anything to the stub as a result.
>> 
>> When I dumped the line table using both readelf and lldb, they were 
>> completely reasonable – almost every line until the end had an entry – there 
>> was no cut off at line #70.
>> 
>> At this point, I’m unsure if I’m doing something wrong, or if lldb-mi is 
>> having some difficulty with my MIPS binary. 
>> 
>> I’m building with the following options:
>> 
>> clang -std=c++14 -mcompact-branches=always -fasynchronous-unwind-tables 
>> -funwind-tables -fexceptions -fcxx-exceptions -mips32r6 -O0 -g -glldb ...
>> 
>> lld --discard-none -znorelro --eh-frame-hdr ...
>> 
>> And the resultant binary is here: 
>> http://filebin.ca/2tJzo2LLBJWO/MipsTest.bin (if you wish something to 
>> analyze).
>> 
>> I’ve also uploaded the rather poor code for Main.cpp here: 
>> https://paste.ee/p/WYs8Y
>> 
>> I’ve also tested this on a second source file in the ELF (‘Recoder.cpp’) 
>> which stops working at a lower line number, but has similar behavior – 
>> there’s a hard cut-off where lldb stops working with breakpoints. The line 
>> table for that file also seems fine.
>> 
>> Just for example, when I set a breakpoint at or below 70 (note, I get the 
>> same behavior when not specifying -H):
>> 
>> break set -H -f Main.cpp -l 70
>> (gdb)
>> =breakpoint-created,bkpt={number="1",type="breakpoint",disp="keep",en
>> a 
>> 

Re: [lldb-dev] Not able to set breakpoints above line #70 in lldb-mi.

[Michael Kuklinski via lldb-dev]

Those are the same results I get - however, when actually attached to the 
remote target, line 70 sends a Z0 packet, whereas line 72 sends absolutely 
nothing, regardless of the order.

I am on LLDB revision 279920, and LLVM revision 279925.

Michael

-Original Message-
From: Greg Clayton [mailto:gclay...@apple.com] 
Sent: Tuesday, August 30, 2016 10:41 AM
To: Michael Kuklinski 
Cc: lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] Not able to set breakpoints above line #70 in lldb-mi.

Seems to work for me just fine with your binary:

lldb /Volumes/work/gclayton/Downloads/MipsTest.bin
(lldb) target create "/Volumes/work/gclayton/Downloads/MipsTest.bin"
Current executable set to '/Volumes/work/gclayton/Downloads/MipsTest.bin' 
(mipsr6el).
(lldb) break set -H -f Main.cpp -l 70
Breakpoint 1: where = MipsTest.bin`main + 520 at Main.cpp:70, address = 
0x00013488
(lldb) break set -H -f Main.cpp -l 72
Breakpoint 2: where = MipsTest.bin`main + 544 at Main.cpp:72, address = 
0x000134a0
(lldb) b
Current breakpoints:
1: file = 'Main.cpp', line = 70, exact_match = 0, locations = 1
  1.1: where = MipsTest.bin`main + 520 at Main.cpp:70, address = 
MipsTest.bin[0x00013488], unresolved, hit count = 0 

2: file = 'Main.cpp', line = 72, exact_match = 0, locations = 1
  2.1: where = MipsTest.bin`main + 544 at Main.cpp:72, address = 
MipsTest.bin[0x000134a0], unresolved, hit count = 0 

You don't need to use lldb-mi to reproduce this. Command line LLDB should give 
you the same results.

What version of LLDB are you using?

> On Aug 30, 2016, at 2:45 AM, Michael Kuklinski via lldb-dev 
>  wrote:
> 
> Hello,
>  
> I’m having an issue setting breakpoints using lldb-mi.
>  
> I am trying to run a C++ program (which is itself a brainfsck interpreter), 
> compiled for MIPS32r6 using Clang, linked with lld, and am trying to use 
> lldb-mi as the debugger. I am using lldb-mi as my primary use for it is as an 
> intermediary for a visual debugger, but I get the same behavior when using it 
> myself.
>  
> Whenever I try to set a reasonable breakpoint at or below line #70 in 
> Main.cpp, it works – it is resolved, it sends a Z0 packet to the gdb stub, 
> and it works. However, when I attempt to set any breakpoint above line #70, 
> it comes up as ‘unresolved’ (though the addresses shown in the list seem 
> reasonable) and does not submit anything to the stub as a result.
>  
> When I dumped the line table using both readelf and lldb, they were 
> completely reasonable – almost every line until the end had an entry – there 
> was no cut off at line #70.
>  
> At this point, I’m unsure if I’m doing something wrong, or if lldb-mi is 
> having some difficulty with my MIPS binary. 
>  
> I’m building with the following options:
> 
> clang -std=c++14 -mcompact-branches=always -fasynchronous-unwind-tables 
> -funwind-tables -fexceptions -fcxx-exceptions -mips32r6 -O0 -g -glldb ...
>  
> lld --discard-none -znorelro --eh-frame-hdr ...
>  
> And the resultant binary is here: http://filebin.ca/2tJzo2LLBJWO/MipsTest.bin 
> (if you wish something to analyze).
>  
> I’ve also uploaded the rather poor code for Main.cpp here: 
> https://paste.ee/p/WYs8Y
>  
> I’ve also tested this on a second source file in the ELF (‘Recoder.cpp’) 
> which stops working at a lower line number, but has similar behavior – 
> there’s a hard cut-off where lldb stops working with breakpoints. The line 
> table for that file also seems fine.
>  
> Just for example, when I set a breakpoint at or below 70 (note, I get the 
> same behavior when not specifying -H):
>  
> break set -H -f Main.cpp -l 70
> (gdb)
> =breakpoint-created,bkpt={number="1",type="breakpoint",disp="keep",ena
> bled="y",addr="0x00013488",func="main",file="Main.cpp",fullnam
> e="D:\Proj 
> ects\MipsTest2\MipsTest/Main.cpp",line="70",times="0",original-locatio
> n="Main.cpp:70"}
> (gdb)
> =breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",en
> abled="y",addr="0x00013488",func="main",file="Main.cpp",fullna
> me="D:\Pro 
> jects\MipsTest2\MipsTest/Main.cpp",line="70",times="0",original-locati
> on="Main.cpp:70"}
>  
> And this is what I see when I set a breakpoint after 70:
> 
> break set -H -f Main.cpp -l 72
> (gdb)
> =breakpoint-created,bkpt={number="2",type="breakpoint",disp="keep",ena
> bled="y",addr="0x000134a0",func="main",file="Main.cpp",fullnam
> e="D:\Proj 
> ects\MipsTest2\MipsTest/Main.cpp",line="72",times="0",original-locatio
> n="Main.cpp:72"}
>  
> However, the list looks as such:
>  
> break list
> Current breakpoints:
> 1: file = 'Main.cpp', line = 70, exact_match = 0, locations = 1, resolved = 
> 1, hit count = 1
>   1.1: where = MipsTest.bin`main + 520 at Main.cpp:70, address = 
> 0x00013488, resolved, hit count = 1
>  
> 2: file = 'Main.cpp', line = 72, exact_match = 0, locations = 1
>   2.1: where = MipsTest.bin`main + 544 at Main.cpp:72, address = 
> MipsTest.bin[0x000134a0], unresolved, 

Re: [lldb-dev] Not able to set breakpoints above line #70 in lldb-mi.

[Michael Kuklinski via lldb-dev]

I never see a Z0 or a Z1 packet for those addresses. Anything above Line 70, it 
never tries to send a packet to my stub to indicate that it wishes to place a 
breakpoint. I get the same behavior using -H that I do without. The system the 
stub is attached to is an emulator, so there's absolutely nothing special about 
those addresses. The stub can also support an arbitrary number of breakpoints 
(hardware and software).

In fact, when I specify, say, Line 72, it sends absolutely nothing to the stub. 
When I specify Line 70, I see:

> \03
< S 11
> Z1,13488,4
< OK
> c
< OK

Which appears to be a sane sequence. However, it doesn’t appear to be doing 
anything for higher addresses. It doesn't ever try to read them or see if 
they're valid. This is also the behavior I see when Line 72 is the first 
breakpoint I try to set, so I'm not sure how LLDB is coming to the conclusion 
that it cannot resolve it, as it's never actually trying to set the breakpoint 
on the stub.

In this case, Line 72 reporting as address 0x13384 - 'memory read 0x13384' 
worked without issue on that address.

Michael

-Original Message-
From: jing...@apple.com [mailto:jing...@apple.com] 
Sent: Tuesday, August 30, 2016 11:04 AM
To: Michael Kuklinski 
Cc: lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] Not able to set breakpoints above line #70 in lldb-mi.

"unresolved" means that we know what address we want to set a breakpoint at, 
but for some reason can't.  For instance, if you were using -H and ran out of 
hardware breakpoints, then the subsequent breakpoints would never get resolved, 
since we can't implement them.

Anyway, going from unresolved -> resolved has nothing to do with the line 
table.  That is only used to figure out what address we should use.  So it 
isn't surprising that that looks okay.

What you need to do instead is figure out why we can't implement the breakpoint 
at that address.  Do we send a Z0 packet for that address as well as the 
others?  Can you read from the memory at the address of the breakpoints that 
aren't getting set?  Write to them?  

Jim
  


> On Aug 30, 2016, at 2:45 AM, Michael Kuklinski via lldb-dev 
>  wrote:
> 
> Hello,
>  
> I’m having an issue setting breakpoints using lldb-mi.
>  
> I am trying to run a C++ program (which is itself a brainfsck interpreter), 
> compiled for MIPS32r6 using Clang, linked with lld, and am trying to use 
> lldb-mi as the debugger. I am using lldb-mi as my primary use for it is as an 
> intermediary for a visual debugger, but I get the same behavior when using it 
> myself.
>  
> Whenever I try to set a reasonable breakpoint at or below line #70 in 
> Main.cpp, it works – it is resolved, it sends a Z0 packet to the gdb stub, 
> and it works. However, when I attempt to set any breakpoint above line #70, 
> it comes up as ‘unresolved’ (though the addresses shown in the list seem 
> reasonable) and does not submit anything to the stub as a result.
>  
> When I dumped the line table using both readelf and lldb, they were 
> completely reasonable – almost every line until the end had an entry – there 
> was no cut off at line #70.
>  
> At this point, I’m unsure if I’m doing something wrong, or if lldb-mi is 
> having some difficulty with my MIPS binary. 
>  
> I’m building with the following options:
> 
> clang -std=c++14 -mcompact-branches=always -fasynchronous-unwind-tables 
> -funwind-tables -fexceptions -fcxx-exceptions -mips32r6 -O0 -g -glldb ...
>  
> lld --discard-none -znorelro --eh-frame-hdr ...
>  
> And the resultant binary is here: http://filebin.ca/2tJzo2LLBJWO/MipsTest.bin 
> (if you wish something to analyze).
>  
> I’ve also uploaded the rather poor code for Main.cpp here: 
> https://paste.ee/p/WYs8Y
>  
> I’ve also tested this on a second source file in the ELF (‘Recoder.cpp’) 
> which stops working at a lower line number, but has similar behavior – 
> there’s a hard cut-off where lldb stops working with breakpoints. The line 
> table for that file also seems fine.
>  
> Just for example, when I set a breakpoint at or below 70 (note, I get the 
> same behavior when not specifying -H):
>  
> break set -H -f Main.cpp -l 70
> (gdb)
> =breakpoint-created,bkpt={number="1",type="breakpoint",disp="keep",ena
> bled="y",addr="0x00013488",func="main",file="Main.cpp",fullnam
> e="D:\Proj 
> ects\MipsTest2\MipsTest/Main.cpp",line="70",times="0",original-locatio
> n="Main.cpp:70"}
> (gdb)
> =breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",en
> abled="y",addr="0x00013488",func="main",file="Main.cpp",fullna
> me="D:\Pro 
> jects\MipsTest2\MipsTest/Main.cpp",line="70",times="0",original-locati
> on="Main.cpp:70"}
>  
> And this is what I see when I set a breakpoint after 70:
> 
> break set -H -f Main.cpp -l 72
> (gdb)
> =breakpoint-created,bkpt={number="2",type="breakpoint",disp="keep",ena
> bled="y",addr="0x000134a0",func="main",file="Main.cpp",fullnam
> 

Re: [lldb-dev] Not able to set breakpoints above line #70 in lldb-mi.

[Michael Kuklinski via lldb-dev]

I never see a Z0 or a Z1 packet for those addresses. Anything above Line 70, it 
never tries to send a packet to my stub to indicate that it wishes to place a 
breakpoint. I get the same behavior using -H that I do without. The system the 
stub is attached to is an emulator, so there's absolutely nothing special about 
those addresses. The stub can also support an arbitrary number of breakpoints 
(hardware and software).

In fact, when I specify, say, Line 72, it sends absolutely nothing to the stub. 
When I specify Line 70, I see:

> \03
< S 11
> Z1,13488,4
< OK
> c
< OK

Which appears to be a sane sequence. However, it doesn’t appear to be doing 
anything for higher addresses. It doesn't ever try to read them or see if 
they're valid. This is also the behavior I see when Line 72 is the first 
breakpoint I try to set, so I'm not sure how LLDB is coming to the conclusion 
that it cannot resolve it, as it's never actually trying to set the breakpoint 
on the stub.

In this case, Line 72 reporting as address 0x13384 - 'memory read 0x13384' 
worked without issue on that address.

Michael

-Original Message-
From: jing...@apple.com [mailto:jing...@apple.com] 
Sent: Tuesday, August 30, 2016 11:04 AM
To: Michael Kuklinski 
Cc: lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] Not able to set breakpoints above line #70 in lldb-mi.

"unresolved" means that we know what address we want to set a breakpoint at, 
but for some reason can't.  For instance, if you were using -H and ran out of 
hardware breakpoints, then the subsequent breakpoints would never get resolved, 
since we can't implement them.

Anyway, going from unresolved -> resolved has nothing to do with the line 
table.  That is only used to figure out what address we should use.  So it 
isn't surprising that that looks okay.

What you need to do instead is figure out why we can't implement the breakpoint 
at that address.  Do we send a Z0 packet for that address as well as the 
others?  Can you read from the memory at the address of the breakpoints that 
aren't getting set?  Write to them?  

Jim
  


> On Aug 30, 2016, at 2:45 AM, Michael Kuklinski via lldb-dev 
>  wrote:
> 
> Hello,
>  
> I’m having an issue setting breakpoints using lldb-mi.
>  
> I am trying to run a C++ program (which is itself a brainfsck interpreter), 
> compiled for MIPS32r6 using Clang, linked with lld, and am trying to use 
> lldb-mi as the debugger. I am using lldb-mi as my primary use for it is as an 
> intermediary for a visual debugger, but I get the same behavior when using it 
> myself.
>  
> Whenever I try to set a reasonable breakpoint at or below line #70 in 
> Main.cpp, it works – it is resolved, it sends a Z0 packet to the gdb stub, 
> and it works. However, when I attempt to set any breakpoint above line #70, 
> it comes up as ‘unresolved’ (though the addresses shown in the list seem 
> reasonable) and does not submit anything to the stub as a result.
>  
> When I dumped the line table using both readelf and lldb, they were 
> completely reasonable – almost every line until the end had an entry – there 
> was no cut off at line #70.
>  
> At this point, I’m unsure if I’m doing something wrong, or if lldb-mi is 
> having some difficulty with my MIPS binary. 
>  
> I’m building with the following options:
> 
> clang -std=c++14 -mcompact-branches=always -fasynchronous-unwind-tables 
> -funwind-tables -fexceptions -fcxx-exceptions -mips32r6 -O0 -g -glldb ...
>  
> lld --discard-none -znorelro --eh-frame-hdr ...
>  
> And the resultant binary is here: http://filebin.ca/2tJzo2LLBJWO/MipsTest.bin 
> (if you wish something to analyze).
>  
> I’ve also uploaded the rather poor code for Main.cpp here: 
> https://paste.ee/p/WYs8Y
>  
> I’ve also tested this on a second source file in the ELF (‘Recoder.cpp’) 
> which stops working at a lower line number, but has similar behavior – 
> there’s a hard cut-off where lldb stops working with breakpoints. The line 
> table for that file also seems fine.
>  
> Just for example, when I set a breakpoint at or below 70 (note, I get the 
> same behavior when not specifying -H):
>  
> break set -H -f Main.cpp -l 70
> (gdb)
> =breakpoint-created,bkpt={number="1",type="breakpoint",disp="keep",ena
> bled="y",addr="0x00013488",func="main",file="Main.cpp",fullnam
> e="D:\Proj 
> ects\MipsTest2\MipsTest/Main.cpp",line="70",times="0",original-locatio
> n="Main.cpp:70"}
> (gdb)
> =breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",en
> abled="y",addr="0x00013488",func="main",file="Main.cpp",fullna
> me="D:\Pro 
> jects\MipsTest2\MipsTest/Main.cpp",line="70",times="0",original-locati
> on="Main.cpp:70"}
>  
> And this is what I see when I set a breakpoint after 70:
> 
> break set -H -f Main.cpp -l 72
> (gdb)
> =breakpoint-created,bkpt={number="2",type="breakpoint",disp="keep",ena
> bled="y",addr="0x000134a0",func="main",file="Main.cpp",fullnam
> 

[lldb-dev] [Bug 30192] Talking: 1.800.681.7208 webrööt antivirus customer service Phone number

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=30192

Eugene Zelenko  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||eugene.zele...@gmail.com
 Resolution|--- |INVALID

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Symbol Server for everyone.

[Jim Ingham via lldb-dev]

The "dsymForUUID" tool doesn't handle copying source files around - we tend to 
just remote mount them.  But we do include these keys in the return plist so 
that lldb can automatically remap the source files from where they were at 
build time to where they are at debug time.  So if your symbol server copies 
files locally and they aren't in the same location as at build time, you might 
want to play a similar trick on your end.

Jim

> On Aug 30, 2016, at 7:18 AM, Taras Tsugrii via lldb-dev 
>  wrote:
> 
> DBGBuildSourcePath
> /path/to/build/sources
> DBGSourcePath
> /path/to/actual/sources

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

Re: [lldb-dev] Not able to set breakpoints above line #70 in lldb-mi.

[Greg Clayton via lldb-dev]

Seems to work for me just fine with your binary:

lldb /Volumes/work/gclayton/Downloads/MipsTest.bin
(lldb) target create "/Volumes/work/gclayton/Downloads/MipsTest.bin"
Current executable set to '/Volumes/work/gclayton/Downloads/MipsTest.bin' 
(mipsr6el).
(lldb) break set -H -f Main.cpp -l 70
Breakpoint 1: where = MipsTest.bin`main + 520 at Main.cpp:70, address = 
0x00013488
(lldb) break set -H -f Main.cpp -l 72
Breakpoint 2: where = MipsTest.bin`main + 544 at Main.cpp:72, address = 
0x000134a0
(lldb) b
Current breakpoints:
1: file = 'Main.cpp', line = 70, exact_match = 0, locations = 1
  1.1: where = MipsTest.bin`main + 520 at Main.cpp:70, address = 
MipsTest.bin[0x00013488], unresolved, hit count = 0 

2: file = 'Main.cpp', line = 72, exact_match = 0, locations = 1
  2.1: where = MipsTest.bin`main + 544 at Main.cpp:72, address = 
MipsTest.bin[0x000134a0], unresolved, hit count = 0 

You don't need to use lldb-mi to reproduce this. Command line LLDB should give 
you the same results.

What version of LLDB are you using?

> On Aug 30, 2016, at 2:45 AM, Michael Kuklinski via lldb-dev 
>  wrote:
> 
> Hello,
>  
> I’m having an issue setting breakpoints using lldb-mi.
>  
> I am trying to run a C++ program (which is itself a brainfsck interpreter), 
> compiled for MIPS32r6 using Clang, linked with lld, and am trying to use 
> lldb-mi as the debugger. I am using lldb-mi as my primary use for it is as an 
> intermediary for a visual debugger, but I get the same behavior when using it 
> myself.
>  
> Whenever I try to set a reasonable breakpoint at or below line #70 in 
> Main.cpp, it works – it is resolved, it sends a Z0 packet to the gdb stub, 
> and it works. However, when I attempt to set any breakpoint above line #70, 
> it comes up as ‘unresolved’ (though the addresses shown in the list seem 
> reasonable) and does not submit anything to the stub as a result.
>  
> When I dumped the line table using both readelf and lldb, they were 
> completely reasonable – almost every line until the end had an entry – there 
> was no cut off at line #70.
>  
> At this point, I’m unsure if I’m doing something wrong, or if lldb-mi is 
> having some difficulty with my MIPS binary. 
>  
> I’m building with the following options:
> 
> clang -std=c++14 -mcompact-branches=always -fasynchronous-unwind-tables 
> -funwind-tables -fexceptions -fcxx-exceptions -mips32r6 -O0 -g -glldb ...
>  
> lld --discard-none -znorelro --eh-frame-hdr ...
>  
> And the resultant binary is here: http://filebin.ca/2tJzo2LLBJWO/MipsTest.bin 
> (if you wish something to analyze).
>  
> I’ve also uploaded the rather poor code for Main.cpp here: 
> https://paste.ee/p/WYs8Y
>  
> I’ve also tested this on a second source file in the ELF (‘Recoder.cpp’) 
> which stops working at a lower line number, but has similar behavior – 
> there’s a hard cut-off where lldb stops working with breakpoints. The line 
> table for that file also seems fine.
>  
> Just for example, when I set a breakpoint at or below 70 (note, I get the 
> same behavior when not specifying -H):
>  
> break set -H -f Main.cpp -l 70
> (gdb)
> =breakpoint-created,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x00013488",func="main",file="Main.cpp",fullname="D:\Proj
> ects\MipsTest2\MipsTest/Main.cpp",line="70",times="0",original-location="Main.cpp:70"}
> (gdb)
> =breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x00013488",func="main",file="Main.cpp",fullname="D:\Pro
> jects\MipsTest2\MipsTest/Main.cpp",line="70",times="0",original-location="Main.cpp:70"}
>  
> And this is what I see when I set a breakpoint after 70:
> 
> break set -H -f Main.cpp -l 72
> (gdb)
> =breakpoint-created,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr="0x000134a0",func="main",file="Main.cpp",fullname="D:\Proj
> ects\MipsTest2\MipsTest/Main.cpp",line="72",times="0",original-location="Main.cpp:72"}
>  
> However, the list looks as such:
>  
> break list
> Current breakpoints:
> 1: file = 'Main.cpp', line = 70, exact_match = 0, locations = 1, resolved = 
> 1, hit count = 1
>   1.1: where = MipsTest.bin`main + 520 at Main.cpp:70, address = 0x00013488, 
> resolved, hit count = 1
>  
> 2: file = 'Main.cpp', line = 72, exact_match = 0, locations = 1
>   2.1: where = MipsTest.bin`main + 544 at Main.cpp:72, address = 
> MipsTest.bin[0x000134a0], unresolved, hit count = 0
> 
> Note that the address seems completely reasonable but it remains unresolved, 
> and does not submit anything to the stub.
>  
> Thanks for any help or insight you might be able to provide,
> Michael
>  
> ___
> 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] [Bug 11714] Cross compiling lldb is broken

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=11714

Tamas Berghammer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||tbergham...@google.com
 Resolution|--- |FIXED

--- Comment #2 from Tamas Berghammer  ---
The autoconf+make based build system have been removed from LLDB (and LLVM,
Clang, etc...) and cross compiling using cmake is working in general (see
http://lldb.llvm.org/build)

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Symbol Server for everyone.

[Taras Tsugrii via lldb-dev]

Thanks a lot Greg for such a detailed response! Locating dSYM bundles is indeed 
very similar and in fact, since it's probably more popular than inlined 
symbols, it will have to be extended to look for symbols on a symbol server as 
well.


The only reason I didn't consider Symbols.h initially was because it does not 
seem to handle source files, which would be nice to support as well. But I 
think it's probably a good start indeed.


Thanks again Greg!


From: Greg Clayton 
Sent: Monday, August 29, 2016 9:34:34 AM
To: Taras Tsugrii
Cc: lldb-dev@lists.llvm.org; Kevin Frei
Subject: Re: [lldb-dev] Symbol Server for everyone.

If you want to go agnostic, then you can just integrate into the following 
functions from Symbols.h:

//--
// Locate the symbol file given a module specification.
//
// Locating the file should happen only on the local computer or using
// the current computers global settings.
//--
static FileSpec
Symbols::LocateExecutableSymbolFile(const ModuleSpec _spec);

//--
// Locate the object and symbol file given a module specification.
//
// Locating the file can try to download the file from a corporate build
// repository, or using any other means necessary to locate both the
// unstripped object file and the debug symbols.
// The force_lookup argument controls whether the external program is called
// unconditionally to find the symbol file, or if the user's settings are
// checked to see if they've enabled the external program before calling.
//
//--
static bool
Symbols::DownloadObjectAndSymbolFile (ModuleSpec _spec, bool 
force_lookup = true);

};

Note that we have an implementation for MacOSX that uses DebugSymbols.framework 
which is available on all Apple systems. There are many ways to track down a 
symbol file that is located locally and remotely. See the settings that you can 
set by checking out the details:

https://urldefense.proofpoint.com/v2/url?u=http-3A__lldb.llvm.org_symbols.html=DQIFAw=5VD0RTtNlTh3ycd41b3MUw=jqaYv5aDYHR_MGTz1rkWPg=-5Rr7M5kMrCwSi6BQuqsUTJAykHNh1lFc8VoQ-o04Lo=L60EDa6WXvcYW9pNuNvrpquyvVdP4iBc5FE4qb4hYHc=

We allow a command line executable to be run that returns a plist. See the 
section labeled "SHELL SCRIPT PROPERTY LIST FORMAT". You basically run a shell 
command that takes arguments that are either a path to a file on disk, or a 
UUID that it is supposed to locate. The shell script can then use any method 
it wants to in order to find the symbol file you requested.

Apple has a shell tool named "dsymForUUID" that will do such a thing. It 
currently uses a custom database to do the lookup and return the correct 
values. The information the plist returns looks like:


https://urldefense.proofpoint.com/v2/url?u=http-3A__www.apple.com_DTDs_PropertyList-2D1.0.dtd=DQIFAw=5VD0RTtNlTh3ycd41b3MUw=jqaYv5aDYHR_MGTz1rkWPg=-5Rr7M5kMrCwSi6BQuqsUTJAykHNh1lFc8VoQ-o04Lo=C8MShlvBsw1qReInCgb5ioT8XGcyGw7RsXGrl3lmO8I=
 ">


23516BE4-29BE-350C-91C9-F36E7999F0F1

DBGArchitecture
i386
DBGBuildSourcePath
/path/to/build/sources
DBGSourcePath
/path/to/actual/sources
DBGDSYMPath
/path/to/foo.dSYM/Contents/Resources/DWARF/foo
DBGSymbolRichExecutable
/path/to/unstripped/executable

A40597AA-5529-3337-8C09-D8A014EB1578

DBGArchitecture
x86_64
DBGBuildSourcePath
/path/to/build/sources
DBGSourcePath
/path/to/actual/sources
DBGDSYMPath
/path/to/foo.dSYM/Contents/Resources/DWARF/foo
DBGSymbolRichExecutable
/path/to/unstripped/executable





Note that this format will tell us where the unstripped executable lives, and 
also allows for source remapping. The DBGBuildSourcePath value says what the 
path was when the binary was built (and what is in the debug info), and 
DBGSourcePath says that the paths should be when actually used (where they will 
live forever on a build server). This allows our builders to build binary in 
say "/tmp/project/lldb" and then copy the sources to where they will live 
permanently in "/build/server1/project/lldb/lldb-1.2.3.4". The "DBGDSYMPath" 
key tells us where the symbol file is.

So our currently Apple solution is:
1 - check that the debug info isn't already in the object file
2 - check for the symbols in proximity to the executable (same directory, at 
the bundle level, and a few other 

Re: [lldb-dev] Python3 compatibility for the API

[Luke Drummond via lldb-dev]

Hi Zachary, Peter

On 30/08/16 00:14, Zachary Turner via lldb-dev wrote:

Right, the existing version that is built and what you are using links
directly against a 2.7 libpython at compile time.  So you would probably
need to build LLDB from source and tweak the build system to make it
possible to link against your 3.x version of python.  There's some build
instructions on the website .  I know
there's a few linux developers around here, so it's possible someone
else would be interested in making this work as well, but I don't know
that it's on anyone's immediate timeline.


We build lldb against python3 regularly, because - as Zachary said - 
this is the only way to get scripting support on windows. To link 
against python3 on Linux you *should* just need the correct headers 
installed, and invoke CMake with the correct python path. For Ubuntu:


```
sudo apt install python3-dev
cmake "$PATH_TO_LLVM_SRC" -DPYTHON_EXECUTABLE:FILEPATH=$(which python3)
```

*should* give you everything you need. However, you may see that cmake 
picks up the python3 interpreter correctly, but tries to link against 
the python2.7 library.


-- Found PythonInterp: /usr/bin/python3 (found version "3.5.2")
[...]
-- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found 
version "2.7.12")


This appears to be due to a problem in LLVM's CMakeLists.txt specifying 
support for 2.7 only. I have a patch to fix the issue awaiting review 
[here](https://reviews.llvm.org/D20825) which should fix the issue on 
Linux when multiple pythons are installed. It may be worth applying this 
patch locally and see how you get on.


Hope that helps

Best

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

[lldb-dev] [Bug 30192] New: Talking: 1.800.681.7208 webrööt antivirus customer service Phone number

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=30192

Bug ID: 30192
   Summary: Talking:1.800.681.7208 webrööt antivirus customer
service Phone number
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: c...@mailinator.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

Description:  Talk:1.800.681.7208 webroot antivirus customer service Phone
number Talk:1.800.681.7208 webroot antivirus customer service Phone number we
provide support for all antiviruss drivers webroot antivirus helpline number
1800 681 7208 webroot antivirus helpline number 1800 681 7208 webroot antivirus
helpline number webroot antivirus 1800 681 7208 Technical support phone number
customer care phone number 1800 681 7208 webroot antivirus customer service
phone number customer care phone number 1800 681 7208 webroot antivirus tech
support phone number 800 681 7208 webroot antivirus customer care number
webroot antivirus helpline number1800 681 7208 webroot antivirus tech support
phone number…webroot antivirus customer care number, support phone number 1800
681 7208 webroot antivirus tech support phone number…webroot antivirus customer
care number, support phone number webroot 1800 681 7208 webroot antivirus
support phone number…webroot antivirus customer support phone number webroot
1800 681 7208 webroot antivirus support phone number…webroot antivirus customer
support phone number 1800 681 7208 webroot antivirus customer service in usa
webroot antivirus live customer support webroot toll free number USA 1800 681
7208 webroot Technical Support Services USA webroot customer support toll free
number USA 1800 681 7208 webroot customer service phone numbers USA webroot
customer support toll free number 1800 681 7208 webroot Customer Support USA
webroot customer service phone numbers webroot Customer Service 1800 681 7208
webroot Technical Support Number webroot antivirus live microsoft customer
support toll free number 1800 681 7208 webroot Customer Service USA webroot
customer service phone numbers 1800 681 7208 webroot Support Number USA webroot
tech support phone webroot antivirus live customer support phone number 1800
681 7208 webroot tech support chat USA webroot customer support number 1800 681
7208 webroot tech support phone number contact webroot customer support USA
1800 681 7208 webroot customer service USA webroot tech support phone number
USA 1800 681 7208 webroot customer service phone number USA webroot antivirus
live customer support phone number 1800 681 7208 webroot customer support chat
Microsoft live customer support 1800 681 7208 webroot antivirus live customer
support webroot tech support phone number 1800 681 7208 contact webroot
customer support USA webroot antivirus live customer support phone number 1800
681 7208 contact webroot customer support number USA webroot antivirus live
customer support phone number 1800 681 7208 webroot fax machine toll free
number USA webroot antivirus live customer support phone number webroot
Technical Support Services 1800 681 7208 webroot tech support phone number USA
webroot Technical Support Services webroot customer support toll free number
1800 681 7208 webroot Technical Support Services USA webroot antivirus live
customer support phone number 1800 681 7208 webroot technical support phone
number USA webroot antivirus live customer support phone number 1800 681 7208
webroot password recovery phone support USA webroot tech support phone number
USA webroot Technical Support Services 1800 681 7208 contact webroot technical
support phone number USA webroot antivirus live customer support phone number
1800 681 7208 webroot technical support live chat webroot tech support phone
number USA 1800 681 7208 webroot customer support toll free number USA webroot
antivirus live customer support phone number 1800 681 7208 webroot help number
contact USA webroot antivirus live customer support phone number 1800 681 7208
webroot helpline phone number USA webroot tech support phone fax machine
support 1800 681 7208 webroot antivirus live customer support phone number USA
webroot customer support toll free number 1800 681 7208 fax machine webroot
customer support number USA webroot antivirus live customer support phone
number 1800 681 7208 create new antivirus webroot Live fax machine account USA
new webroot antivirus address USA 1800 681 7208 create new antivirus webroot
Live recover antivirus password USA make an antivirus account 1800 681 7208
make an antivirus account fax machine set up new webroot antivirus USA create
new antivirus webroot Live fax machine account webroot Password recovery Call
1800 681 7208 webroot Password Problems webroot Support Phone Number webroot
Phone Number webroot Support Technicians 

Re: [lldb-dev] Python3 compatibility for the API

[Pavel Labath via lldb-dev]

We don't have any immediate plans to make lldb work with python 3 on
linux. However, I would be willing to guide you through making that
work. As Zachary pointed out, it should be fairly simple, given that
it already works on windows.

I don't think you'll be able to avoid building your own copy of lldb,
so I think you should start by making sure that you can build a
working lldb trunk with python2. Then we can figure out how to get
python 3 working.

BTW, linux support in lldb 3.6 was still quite flaky. I'd recommend
going at least to 3.8 to get a more stable experience.

pl



On 30 August 2016 at 00:14, Zachary Turner via lldb-dev
 wrote:
> Right, the existing version that is built and what you are using links
> directly against a 2.7 libpython at compile time.  So you would probably
> need to build LLDB from source and tweak the build system to make it
> possible to link against your 3.x version of python.  There's some build
> instructions on the website.  I know there's a few linux developers around
> here, so it's possible someone else would be interested in making this work
> as well, but I don't know that it's on anyone's immediate timeline.
>
> In any case, if you want to try it yourself, the first step would be to get
> a working build (even with 2.7), and once you have that working we can look
> at how to make it link against Python 3.
>
> On Mon, Aug 29, 2016 at 4:07 PM Peter Gebhard  wrote:
>>
>> Hmm…sure? I can try. Feel free to send me any tips.
>>
>> It does show syntax errors when trying to import the existing lldb module
>> in Python 3, however.
>>
>> Thanks,
>> Peter
>>
>> On Aug 29, 2016, at 6:42 PM, Zachary Turner  wrote:
>>
>> 3.6.2 should be new enough, Python 3 has been working for over a year and
>> it's actually the only supported configuration right now on Windows.  Most
>> likely the problem is just that I never updated the build system to work
>> with a platform other than Windows.  Unfortunately, being that I work
>> primarily on Windows, I'm probably not the best person to fix this, but if
>> you want to take a stab at it I can give you some pointers to put you in the
>> right direction.
>>
>> On Mon, Aug 29, 2016 at 3:37 PM Peter Gebhard  wrote:
>>>
>>> Zachary,
>>>
>>> Great to hear! I was trying it out on Ubuntu 15.10 (which has lldb
>>> 3.6.2), and it seemed that the relevant modules were only installed with the
>>> Python 2 packages. Is it an installation issue on my side, or did 3.6.2 not
>>> have your changes yet? I can always install a newer version of lldb if it’s
>>> simply too old.
>>>
>>> Thanks,
>>> Peter
>>>
>>> On Aug 29, 2016, at 6:30 PM, Zachary Turner  wrote:
>>>
>>> Hi,
>>>
>>> LLDB already supports Python 3.  I spent a LONG time making this work.
>>> :)  I've only ever tested the Python 3 support on Windows, and I've only
>>> tested 3.5 and above, but I don't expect any major difficulties getting it
>>> working on another platform, although you may need to tweak the CMake a
>>> little bit to get it building on your platform if it's not Windows.  Please
>>> try it and let me know how it goes.
>>>
>>> What OS and minor version are you planning to use?
>>>
>>> On Mon, Aug 29, 2016 at 3:15 PM Peter Gebhard via lldb-dev
>>>  wrote:

 Hello,

 I am developing a tool which is written in Python3 due to its use of
 some libraries which require it. I am wondering if there is a sane way to
 integrate use of the LLDB Python API into my tool or is there a plan to add
 Python3 support for the LLDB Python API in the near future?

 Thank you,
 Peter

 ___
 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] LLDB Evolution

[Pavel Labath via lldb-dev]

I would definitely welcome more prolific usage of early returns, but I
don't think we can do that before the big reformat. At least some of
those changes will be pretty non-trivial and risky. I'd vote for
making these changes after the reformat. Hopefully the uglyness of the
code will also encourage people to do that more. :)

Another thing we can do to alleviate the nesting level problem is
split code into smaller functions. I see a lot of code which has huge
functions doing complicated things. If that was split into smaller
functions, the code would become much clearer (and less nested).

pl

On 28 August 2016 at 21:37, Tamas Berghammer via lldb-dev
 wrote:
> You can grep for "  {$". With this regex I
> see no false positives and 272 case with 40 or more leading spaces
>
>
> On Sun, 28 Aug 2016, 17:59 Zachary Turner via lldb-dev,
>  wrote:
>>
>> Here it is
>>
>>
>> grep -n '^ \+' . -r -o | awk '{t=length($0);sub(" *$","");printf("%s%d\n",
>> $0, t-length($0));}' | sort -t: -n -k 3 -r | awk 'BEGIN { FS = ":" } ; { if
>> ($3 >= 50) print $0 }'
>> On Sun, Aug 28, 2016 at 9:54 AM Zachary Turner  wrote:
>>>
>>> I tried that, but most of the results (and there are a ton to wade
>>> through) are function parameters that wrapped and align with the opening
>>> paren on the next line.
>>>
>>> Earlier in the thread (i think it was this thread anyway) i posted a bash
>>> incantation that will grep the source tree and return all lines with >= N
>>> leading spaces sorted descending by number of leading spaces. The highest
>>> was about 160 :)
>>>
>>> If you search lldb-dev for awk or sed you'll probably find it
>>> On Sun, Aug 28, 2016 at 9:10 AM Chris Lattner  wrote:

 Can you just grep for “^“ or something?
 That seems like a straight-forward way to find lines that have a ton of
 leading indentation.

 -Chris

 On Aug 27, 2016, at 9:28 AM, Zachary Turner  wrote:

 It will probably be hard to find all the cases.  Unfortunately
 clang-tidy doesn't have a "detect deep indentation" check, but that would 
 be
 pretty useful, so maybe I'll try to add that at some point (although I 
 doubt
 I can get to it before the big reformat).

 Finding all of the egregious cases before the big reformat will present
 a challenge, so I'm not sure if it's better to spend effort trying, or just
 deal with it as we spot code that looks bad because of indentation level.

 On Sat, Aug 27, 2016 at 9:24 AM Chris Lattner 
 wrote:
>
> On Aug 26, 2016, at 6:12 PM, Zachary Turner via lldb-dev
>  wrote:
>
> Back to the formatting issue, there's a lot of code that's going to
> look bad after the reformat, because we have some DEEPLY indented code.
> LLVM has adopted the early return model for this reason.  A huge amount of
> our deeply nested code could be solved by using early returns.
>
>
> FWIW, early returns are part of the LLVM Coding standard:
>
> http://llvm.org/docs/CodingStandards.html#use-early-exits-and-continue-to-simplify-code
>
> So it makes sense for LLDB to adopt this approach at some point.
>
> I don’t have an opinion about whether it happens before or after the
> "big reformat", but I guess I agree with your point that doing it would be
> good to do it for the most egregious cases before the reformat.
>
> -Chris


>> ___
>> 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