[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 <mik...@pixelcarbide.com>
Cc: Greg Clayton <gclay...@apple.com>; 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 
> <lldb-dev@lists.llvm.org> 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 <mik...@pixelcarbide.com>
> 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 
>> <lldb-dev@lists.llvm.org> 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 wo

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 <mik...@pixelcarbide.com>
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 
> <lldb-dev@lists.llvm.org> 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/M

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 <mik...@pixelcarbide.com>
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 
> <lldb-dev@lists.llvm.org> 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=

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 <mik...@pixelcarbide.com>
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 
> <lldb-dev@lists.llvm.org> 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=

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