I've figured out most of what i need from the LLDB api but have a few questions I can't figure out myself:
* How do i get notified of "thread started", "thread finished" events?
* How do i find out when a breakpoint has been bound?
* How can I get notified of when a module is loaded?
* How do I stop a process when it's still running, "Stop" sets a breakpoint, which isn't what i want. Disposing the debugger creates access violations.
(That all said, it besides these few minor issues, it does work quite well)
I've figured out most of what i need from the LLDB api but have a few questions I can't figure out myself:
* How do i get notified of "thread started", "thread finished" events?
We don't currently support thread started & thread finished.
* How do i find out when a breakpoint has been bound?
The target broadcasts "breakpoint changed" notifications. Note that lldb breakpoints remain active as long as they are around and can be set on many locations, so they may be "bound" more than once in the course of the debugging session. Anyway, you get the target broadcaster, and attach a listener to that (listening for the event bit eBroadcastBitBreakpointChanged) and wait on the listener. There are some static functions in SBBreakpoint.h to decode the breakpoint changed events.
* How can I get notified of when a module is loaded?
The target also broadcasts these, the event bits are eBroadcastBitModulesLoaded & Unloaded. These events don't contain any data, you have to look at the module list to figure out what happened. We should add the list of modules changed at some point.
* How do I stop a process when it's still running, "Stop" sets a breakpoint, which isn't what i want. Disposing the debugger creates access violations.
Humm, Stop is the call to use, but it shouldn't need to set a breakpoint. How are you seeing that?
(That all said, it besides these few minor issues, it does work quite well)
I've figured out most of what i need from the LLDB api but have a few questions I can't figure out myself:
* How do i get notified of "thread started", "thread finished" events?
As Jim said, we don't currently support that. Mostly because our MacOSX doesn't support notifying when a thread comes and goes, and there isn't much we can do when a thread does come/go. A static view of thread created and thread destroyed is easy, but if you have a program that is running, it is tricky and probably going to slow down debugging, if you want to keep up with all of the threads that are coming and going.
What are you trying to do?
* How do i find out when a breakpoint has been bound?
Jim explained this quite well, but to emphasize: all of our breakpoints are always resolving when shared libraries come and go. So file + line, and breakpoints by name will continually resolve themselves as your program runs. One breakpoint maps to multiple locations.
* How can I get notified of when a module is loaded?
* How do I stop a process when it's still running, "Stop" sets a breakpoint, which isn't what i want. Disposing the debugger creates access violations.
(That all said, it besides these few minor issues, it does work quite well)
I've figured out most of what i need from the LLDB api but have a few questions I can't figure out myself:
* How do i get notified of "thread started", "thread finished" events?
We don't currently support thread started & thread finished.
Oke I guess I can do without just fine. I can enumerate them when I need the list I guess.
* How do i find out when a breakpoint has been bound?
The target broadcasts "breakpoint changed" notifications. Note that lldb breakpoints remain active as long as they are around and can be set on many locations, so they may be "bound" more than once in the course of the debugging session. Anyway, you get the target broadcaster, and attach a listener to that (listening for the event bit eBroadcastBitBreakpointChanged) and wait on the listener. There are some static functions in SBBreakpoint.h to decode the breakpoint changed events.
* How can I get notified of when a module is loaded?
The target also broadcasts these, the event bits are eBroadcastBitModulesLoaded & Unloaded. These events don't contain any data, you have to look at the module list to figure out what happened. We should add the list of modules changed at some point.
* How do I stop a process when it's still running, "Stop" sets a breakpoint, which isn't what i want. Disposing the debugger creates access violations.
Humm, Stop is the call to use, but it shouldn't need to set a breakpoint. How are you seeing that?
I meant that it lokked like "stop" breaks the debugger where ever it is. I want to kill off the process all together. IE stop debugging all together.
I've figured out most of what i need from the LLDB api but have a
few questions I can't figure out myself:
* How do i get notified of "thread started", "thread finished"
events?
As Jim said, we don't currently support that. Mostly because our
MacOSX doesn't support notifying when a thread comes and goes, and
there isn't much we can do when a thread does come/go. A static view
of thread created and thread destroyed is easy, but if you have a
program that is running, it is tricky and probably going to slow down
debugging, if you want to keep up with all of the threads that are
coming and going.
What are you trying to do?
List the threads active. But I think i can just request this whenever I need it.
* How do i find out when a breakpoint has been bound?
Jim explained this quite well, but to emphasize: all of our
breakpoints are always resolving when shared libraries come and go.
So file + line, and breakpoints by name will continually resolve
themselves as your program runs. One breakpoint maps to multiple
locations.
That's fine. What I wanted to know is if it got bound at all at some point. Before libraries are loaded they are surely unbound, and while they might trigger in multiple places at some point, i just need to know if the user didn't put one at a bad place.
I've figured out most of what i need from the LLDB api but have a few questions I can't figure out myself:
* How do i get notified of "thread started", "thread finished" events?
We don't currently support thread started & thread finished.
Oke I guess I can do without just fine. I can enumerate them when I need the list I guess.
* How do i find out when a breakpoint has been bound?
The target broadcasts "breakpoint changed" notifications. Note that lldb breakpoints remain active as long as they are around and can be set on many locations, so they may be "bound" more than once in the course of the debugging session. Anyway, you get the target broadcaster, and attach a listener to that (listening for the event bit eBroadcastBitBreakpointChanged) and wait on the listener. There are some static functions in SBBreakpoint.h to decode the breakpoint changed events.
* How can I get notified of when a module is loaded?
The target also broadcasts these, the event bits are eBroadcastBitModulesLoaded & Unloaded. These events don't contain any data, you have to look at the module list to figure out what happened. We should add the list of modules changed at some point.
* How do I stop a process when it's still running, "Stop" sets a breakpoint, which isn't what i want. Disposing the debugger creates access violations.
Humm, Stop is the call to use, but it shouldn't need to set a breakpoint. How are you seeing that?
I meant that it lokked like "stop" breaks the debugger where ever it is. I want to kill off the process all together. IE stop debugging all together.
Seems the memory maps for open files are kept open for caching purposes. Is there a way to force close them? On windows an open file means it cannot be written to.
EndRow/EndCol info. I noticed that when I emit debug info I have to do both start and end row/col, but when reading it back I only get start. Is there a way to get this info? (not sure if it's stored)
Seems the memory maps for open files are kept open for caching purposes. Is there a way to force close them? On windows an open file means it cannot be written to.
When you delete a target, it will clean up any orphaned modules which should release your memory mapped files.
EndRow/EndCol info. I noticed that when I emit debug info I have to do both start and end row/col, but when reading it back I only get start. Is there a way to get this info? (not sure if it's stored)
The line tables in DWARF only support a single column for each address, but you can often take the delta between the current line table entry and the next to come up with a range. This wouldn't be hard to add. The line tables internally are stored in a minimal format, and then handed out internally in a less minimal format: lldb_private::LineEntry. To figure out the address range there is already code that looks at the next minimal line table entry to get the next address to compute the size, so we can easily figure out the column range by doing the same thing: if the next line table entry if on the same line, then the end column range is the column from the next line entry, and if not, then it is just the end of the line. This can result is bad columns ranges though when you have line entries for a line in source that aren't next to each other (commonly happens with for loops). So a better algorithm would be the find all line entries with the same line from the same file and look at all the column entries for it.
So, no we don't have it now, but you can add it, but need to be careful and make sure the algorithm that creates the column range isn't too expensive. Maybe it can be computed only on demand with a new API function:
uint32_t
SBLineEntry::GetEndColumn () const;
Then this can take its time and figure out the right answer.