I'm pretty sure this is just a matter of listing, and not a disconnect between the naming feature in Xcode and the underlying feature in lldb. Because these are fully wired together, for now you can use the lldb breakpoint name command to access that breakpoints you've named in the Xcode Breakpoint Editor. For instance, I've named a breakpoint MyBkpt in the Xcode Breakpoint Editor, and then I can go to the Console and see that it has that name: Current breakpoints: 1: file = '/tmp/Whatever/Whatever/main.cpp', line = 12, exact_match = 0, locations = 1, resolved = 1, hit count = 1   Names:     MyBkpt   1.1: where = Whatever`main + 29 at main.cpp:12:13, address = 0x00000001000012ad, resolved, hit count = 1  I can list all the breakpoints with that name by using that specifier in the break list command: 1: file = '/tmp/Whatever/Whatever/main.cpp', line = 12, exact_match = 0, locations = 1, resolved = 1, hit count = 1   Names:     MyBkpt   1.1: where = Whatever`main + 29 at main.cpp:12:13, address = 0x00000001000012ad, resolved, hit count = 1  And I can query for the names I've used already with the break name list command: Name: MyBkpt 1: file = '/tmp/Whatever/Whatever/main.cpp', line = 12, exact_match = 0, locations = 1, resolved = 1, hit count = 1 That's not to say that having Xcode show the breakpoint name more prominently isn't a great suggestion. We try to avoid forcing you to go to the lldb console for important information. But unless I'm missing something in your question, you can get the information you need about your Xcode set breakpoints from the console for now.

First, make sure the breakpoints have been resolved to some actual address. Use the break list command, then check to make sure the breakpoints have locations and are marked as "resolved". If that's not true then for some reason we weren't able to find any locations in code that matched your breakpoint specification. The other thing to watch out for, if you are building your kext with optimization on, is that optimization often changes ordering of execution, and sometimes the line tables don't track that accurately. I've seen cases, for instance, where a breakpoint on the line of an "if" test or "switch" gets moved inside the switch, so that it won't get hit 100% of the time. You can often work around this by moving the breakpoint a little earlier in your code.