0

I am struggling with constant changes to a code written in nasm using os x 64 bit. I find it rather boring having to redefine the line where to make a break point every time (because changing the code, the line changes). So I thought of using a break point referring to a label (as I can do using gdb by the way). However, I have noticed that lldb does not allow to use labels in break points when debugging with nasm code. Do any of you use them? If so, how?

Roberto Rocco
  • 450
  • 2
  • 11
  • 1
    Would inserting an INT 3 instruction work? That'd trap everytime it gets executed. – Olsonist Jan 09 '21 at 03:00
  • 1
    Or invalid syscall see to keep program running without debugger attached https://stackoverflow.com/questions/58227906/how-to-set-a-breakpoint-on-an-assembly-file-using-xcode/58233495#58233495 – Kamil.S Jan 09 '21 at 09:55
  • @Olsonist It would seem to work and actually documenting me a bit about this trap serves just this purpose: "trap to debugger". – Roberto Rocco Jan 10 '21 at 05:42
  • @Kamil.S It is interesting to note the difference (as explained in the link you sent me) between INT 3 and syscall. – Roberto Rocco Jan 10 '21 at 05:53

1 Answers1

2

If the label survives as a real symbol, lldb should be able to set a breakpoint on the symbol. But if the label doesn't survive (it's a local symbol or whatever), lldb would have to dig it out from the debug info. I don't know how nasm represents labels in the debug info, but if gdb can find them then there's some breadcrumbs that lldb should be able to use as well. If you file a bug with your example that shows the problem at http://bugs.llvm.org somebody there can take a look.

You might be able to do this task with the current lldb using a "source regular expression" breakpoint (in lldb break set -p). Since labels come first on the line, a regex like ^ *LABELNAME: should just get the definition of the label and not any other references to it in the source.

More generally, when I have code I know I'm going to want to put a breakpoint on, but I'm still busily editing the code so the line number is changing all the time, I just add a comment like:

someInterestingFunctionCall() // Set a breakpoint here

Then I do:

(lldb) break set -p "Set a breakpoint here" -f MySourceFile.c

That way I can edit the source and move this line around however I need, and the breakpoint will continue to work. nasm supports comments, so you could also just use a comment to tag the line you want to break on.

Jim Ingham
  • 25,260
  • 2
  • 55
  • 63
  • It is exactly the answer to my question, even if to tell the truth, in my case, I find an INT 3 or a syscall much more practical. – Roberto Rocco Jan 10 '21 at 13:24
  • 1
    __builtin_debugtrap is another good way to stop programmatically in the debugger - that's all the debugger does, just from the outside. The downside of traps is that you can't enable & disable them on the fly so they are more useful for error conditions than commonly executed code. And since lldb knows nothing about them it's harder to attach actions to hitting the trap. You could do this with a specific stop-hook, but that's more work and adds conditions that get checked every time you stop so it's less efficient. – Jim Ingham Jan 11 '21 at 18:53