[Lldb-commits] [PATCH] D109738: [lldb] Fix bug 38317 - Address breakpoints don't work if set before the process launches

Jim Ingham via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Mon Oct 11 09:19:02 PDT 2021


jingham added a comment.

In D109738#3054058 <https://reviews.llvm.org/D109738#3054058>, @vadimcn wrote:

>> Is it possible to get your IDE to record the module & the address?
>
> I don't control the definition of the protocol (FWIW it's Microsoft's Debug Adapter Protocol), but I'll look into that, maybe there's a way to sneak in extra information.   In which case, what is the correct way to save/restore instruction breakpoints across lldb runs?   Even if I save module path or UUID, there seems to be no SB API to create a breakpoint using this information.

If you want to save the section relative address info within an lldb session, if you resolve a load address against the Module containing the address (or just resolve the load address using the target when the process is running) will give you a section relative address.

If you are interested in saving it across sessions, I would save the module UUID and the file address in that module.  Then the next time you need to create the breakpoint, look up the module by UUID, and then call ResolveFileAddress and use the SBAddress you get back to resolve the breakpoint.

> What if the module gets recompiled?  I still could end up with my breakpoint slapped in the middle of an instruction.   It seems to me that perfect safety is just impossible here...

Provided the system you are working on has reliable UUID's, the UUID will protect against that.  If you don't have reliable UUID's then you have to fall back to storing mod times or something.

>> More generally, using raw address breakpoints is fallible, and whenever you find yourself doing that you should probably see if you can do anything else.
>> ...
>> This patch as is worries me because it moves us further down the path of passing around raw addresses from run to run, and when that doesn't work it can cause hard to diagnose problems in the running of the process.
>
> I dunno, I guess I am in the camp of "Give a stern warning, but don't second guess the developer".    It's pretty annoying when your tool refuses to do something, which you know is reasonable under the circumstances, not because of a technical limitation, but "for your own good".

The alternative reading is "this is an area where you can get yourself into trouble if you don't do it right, so we should make it easy to do the right thing (always record address breakpoints with modules, and don't be smart about trying to "reset" them on rerun.)  Seems like lldb should take care of that.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109738/new/

https://reviews.llvm.org/D109738



More information about the lldb-commits mailing list