Note, this is just the 'initial' breakpoint description, if you were to do "break list" after creating the breakpoint you will see much more detailed information (and there's a -v flag for even more...) I added the distinction between normal & initial descriptions so we could keep the "break set" responses fairly terse. We originally had more verbose output when the breakpoints were originally created but hoi polloi felt it was too noisy.
I didn't put the brief "where" info in originally just because when you are setting a breakpoint on an address you generally already know why you are setting it there, whereas a symbol breakpoint could resolve to something you didn't expect. But I don't have strong feelings one way or the other about this. You will have to make sure there aren't any test cases that rely on the format of the break output. I added functions (run_break_set...) in test/lldbutil.py to shield test cases from having to know about the description format, but I didn't add one for addresses so there must not have been any uses of the command-line "break set -a" at that point. Some may have crept in, however. Jim > On Apr 2, 2015, at 10:00 AM, Ted Woodward <ted.woodw...@codeaurora.org> wrote: > > When I set a breakpoint at the address of main, I get just the address back: > > (lldb) break set -a `&main` > Breakpoint 1: address = 0x00000000004004f0 > > When I break at main, I get the source line and the address: > > (lldb) settings set target.skip-prologue false > (lldb) b main > Breakpoint 2: where = a.out`main at hello.c:3, address = 0x00000000004004f0 > > Should break set –a also print out symbol, source file and line? > _______________________________________________ > lldb-dev mailing list > lldb-dev@cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
