[lldb-dev] a GUI frontend of LLDB

[jingham at apple.com]

If I build your little main.c (and some foo.c that has a trivial function foo in it) with a fairly recent clang at -O0, then the breakpoint on line 37 gets correctly set on line 37.  Actually the same thing happens at -O3 with a fairly recent clang, clang has been getting better recently at tracking source lines through the optimizer, though this is not always easy to do.

You can check what the line table actually says in lldb with the command:

(lldb) image dump line-table main.c

and see if that makes sense with what you are seeing.  If not, that is most likely a bug in the compiler's line table generation.

Anyway, if you want to pursue this further, you should file a bug with the complete set of files you use, and also what compiler you are using to build them and how you invoke the compiler.

Jim



> On Feb 17, 2015, at 10:59 PM, zephyr zhao <zephyr.git at gmail.com> wrote:
> 
> Hi Jim,
> 
> Unfortunately, it still has the issue:
> 
> For example, for https://github.com/c0deforfun/LLL/blob/master/sample/main/main.c:
> I set bp at line 37 :
>   i = foo(argc,2);  
> (foo is in another CU, so won't be inlined)
> However, GetAddress().GetSymbolContext(lldb.eSymbolContextEverything).GetLineEntry()) shows it's at line 38.
> 
> commandline has the same issue:
> (lldb) b main.c:37
> Breakpoint 1: where = test`main + 192 at main.c:38, address = 0x0000000000400677
> 
> In commandline script:
> >>> ss=lldb.SBStream()
> >>> lldb.target.FindBreakpointByID(1).GetDescription(ss)
> >>> print(ss.GetData())
> SBBreakpoint: id = 1, file = 'main.c', line = 37, locations = 1
> 
> 
> >>> print(lldb.target.FindBreakpointByID(1).GetLocationAtIndex(0).GetAddress().GetSymbolContext(lldb.eSymbolContextEverything).GetLineEntry())
> /home/media/Shared/LLL/sample/main/main.c:38
> 
> 
> I expect a consistent user experience: wherever users clicks a line for bp, a dot will been shown at that line.
> 
> Thanks
> 
> On Tue, Feb 17, 2015 at 9:20 PM, zephyr zhao <zephyr.git at gmail.com> wrote:
> Hi Jim,
> 
> Cool! Thanks a lot! 
> Your analysis is correct.
> Let me try you solution!
> 
> Thanks
> 
> 
> On Tue, Feb 17, 2015 at 11:29 AM, <jingham at apple.com> wrote:
> 
> > On Feb 16, 2015, at 11:01 PM, zephyr zhao <zephyr.git at gmail.com> wrote:
> >
> > Hi,
> >
> > I'm working on a GUI frontend of LLDB which is based on Python 2.7 and Qt 4:
> > https://github.com/c0deforfun/LLL
> >
> > Screenshot of current status:
> > https://raw.githubusercontent.com/c0deforfun/LLL/master/docs/screenshot.png
> >
> > There're still a lot of works to do. It would be really helpful if someone could join the project.
> > Any suggestions or comments will be appreciated too!
> >
> > Btw, I have a question:
> > when users set a breakpoint at some line, SBBreakpointLocation may return a different line No. My current workaround is grep it from SBBreakpoint.GetDescription()
> 
> This can happen when a breakpoint is set on a line that doesn't generate any code.  Then the breakpoint will be moved to the nearest line afterwards that does generate code.  For instance, setting a breakpoint on some code that is in a:
> 
> #if 0
> 
> #endif
> 
> block will cause it to be moved to the line after the #if 0'ed code.  If it is happening for you in code that looks like it is actually getting executed however, then that's a bug (most likely a bug in the line table information, but it could be an lldb bug as well.)
> 
> You don't need to grep GetDescription for the line number, however.  Just get the Location's SBAddress, (SBBreakpointLocation::GetAddress(), then get the SBSymbolContext from the address (SBAddress::GetSymbolContext(lldb.eSymbolContextEverything)).  The symbol context has a SBLineEntry (SBSymbolContext::GetLineEntry()) and that has the file spec & line number.
> 
> Jim
> 
> 
> >
> > Thanks,
> > C0deforfun
> >
> >
> > _______________________________________________
> > lldb-dev mailing list
> > lldb-dev at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
> 
> 
>