vadimcn added a comment. Hi Jim, I think there's a bit of confusion going on here: The original bug was opened by Ted Woodward, and I think his scenario was motivated by embedded debugging. He also provided that example with a breakpoint being set in main.
I've rediscovered this bug independently, while working on an IDE integration project. In my case, the IDE saves just the address of the instruction where a breakpoint was set in the previous debugging session. In the next session, the debug adapter is expected to restore instruction breakpoints using just the absolute addresses; the protocol does not provide for any user interaction. Also, this happens via the SB API, not via LLDB commands. Fortunately, when ASLR is disabled, modules are usually loaded at the same address, so things tend to work out 99% of the time. The other 1%... well, if you are debugging on the assembly instruction level, you are kinda expected to know what you are doing and be prepared to deal with problems like those you've described above. When the target is created, the modules for the target are loaded and > mapped at whatever address is their default load address. Clearly, this isn't happening. From what I can see, section addresses are not known until the process starts running. Maybe this is another bug that needs fixing? Even so, I think that address breakpoints should still function when section addresses aren't known at breakpoint creation time (for whatever reason), if only on a best-effort basis. 3. If the address doesn't fall into any sections, then it would be fine to > assign it to the first section that shows up at that address, but I would > convert it to section relative at that point. This is what I am attempting to do with my patch. Is there something else I should do to make sure I am not regressing other scenarios? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D109738/new/ https://reviews.llvm.org/D109738 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits