Recent

Author Topic: int 3 / fpdebug  (Read 2957 times)

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9754
  • Debugger - SynEdit - and more
    • wiki
int 3 / fpdebug
« on: July 01, 2020, 06:30:23 pm »
https://bugs.freepascal.org/view_user_page.php?id=5532
Quote from: nanobit https://bugs.freepascal.org/view_user_page.php?id=5532

Martin, have you changed something in this regard? In FpDebug:
my F8 workaround (programmatic breakpoint) for all debugger types: "except asm int 3; end; .... end;"
seems to be ignored now after raise exception.create().

I recall that the question if "int 3" should be caught by the debugger had been discussed way back...
Not sure what the outcome was.

Back then there was code to make the debugger realize that the int3 was not by a breakpoint, and was ignored. (Don't recall if it was changed back then)

I have not made any intentional change.
But in the past months (so a while back) the entire stepping was reworked. Could be a side effect.

Thaddy

  • Hero Member
  • *****
  • Posts: 14157
  • Probably until I exterminate Putin.
Re: int 3 / fpdebug
« Reply #1 on: July 01, 2020, 10:31:41 pm »
int 3 is an intentional breakpoint (only supported  for intel/amd) It should always work, because it is a hardware instruction.
Specialize a type, not a var.

PascalDragon

  • Hero Member
  • *****
  • Posts: 5444
  • Compiler Developer
Re: int 3 / fpdebug
« Reply #2 on: July 02, 2020, 09:57:19 am »
int 3 is an intentional breakpoint (only supported  for intel/amd) It should always work, because it is a hardware instruction.

There are also such intentional breakpoints for other architectures. E.g. Visual Studio uses BRK 0xF000 on Aarch64 to implement their __debugbreak() intrinsic.

I'm intensively using such software breakpoints when I can't easily set a breakpoint using the debugger (e.g. when working on FPC's aarch64-win64 support I didn't have any debug information available at first), so when debugging with Lazarus these should be caught as well.

Thaddy

  • Hero Member
  • *****
  • Posts: 14157
  • Probably until I exterminate Putin.
Re: int 3 / fpdebug
« Reply #3 on: July 02, 2020, 10:21:48 am »
There are also such intentional breakpoints for other architectures. E.g. Visual Studio uses BRK 0xF000 on Aarch64 to implement their __debugbreak() intrinsic.
Maybe supply a macro/support for that? I was not aware that it has equivalents on other architectures.
Specialize a type, not a var.

ccrause

  • Hero Member
  • *****
  • Posts: 843
Re: int 3 / fpdebug
« Reply #4 on: July 02, 2020, 11:24:37 am »
There are also such intentional breakpoints for other architectures. E.g. Visual Studio uses BRK 0xF000 on Aarch64 to implement their __debugbreak() intrinsic.
Maybe supply a macro/support for that? I was not aware that it has equivalents on other architectures.
Apologies for drifting further off topic...  Adding support for other targets in fpdebug would be great.  It is still biased towards x86 architecture (because that is where it started I suppose).  However some refactoring is still needed to make it easier to add support for other targets.  Other examples of software breaks:
AVR - BREAK ($9598)
Xtensa - BREAK ($004xx0) & BREAK.N ($Fx2D)

But it is not really that bad, fpdebug is already quite well structured in other aspects. E.g. adding a disassembler or stack frame processing for a new target is relatively easy.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9754
  • Debugger - SynEdit - and more
    • wiki
Re: int 3 / fpdebug
« Reply #5 on: July 02, 2020, 01:53:52 pm »
Adding support (macro / support to fpc) is really a different topic. (And on windows their is afaik an OS function...)

To the debugger, it does not matter how the "int 3" was generated by the compiler. If it is there, and gets executed, then that is what the debugger should care about. (I put it on my todo, to have fpdebug recognizing that....)


As for fpdebug and other architectures, this is a case of having a use case.
That is, such refactoring is likely only to happen, if it is needed.

Currently any target, can have a subclass of TDbgProcess and TDbgThread, and most target specific behaviour will be in there.
The also get their own asm class.

However that distinction was designed to be OS specifics.
Thinks like watchpoints and int 3 are CPU specific. So it is likely that at some point a class representing the CPU will need to be added.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9754
  • Debugger - SynEdit - and more
    • wiki
Re: int 3 / fpdebug
« Reply #6 on: July 02, 2020, 09:00:17 pm »
Should that be "int3" or "int 3"? (space?)

They generate different binary code (they may do the same thing, but still):
Code: ASM  [Select][+][-]
  1. CC                       int3
  2. CD 03                    int $03
  3.  



Experimental code ("int3" only) at https://github.com/User4martin/lazarus/tree/f-fpdebug-int3



One note:
When cross debugging a 32bit app in an 64bit debugger, the app will reach an "int3" in the kernel at sometime during startup (before reaching user code).
So the debugger will stop there too.

I could not test what gdb does (on Windows).  Not tested on Linux (if anyone wants too...., but then the linux kernel may not inject an int3)
Because with gdb (at least up to 8.3, I haven't got any newer yet) you can not cross debug bitness.
With GDB the IDE if correctly configured (even a 64bit ide) launches a 32bit gdb to debug a 32 bit target.

A 64bit IDE has fpdebug build in, so it cannot launch any other bitness.

If one forces the IDE to use a 64bit gdb (8.x) and attempts to debug a 32bit app, gdb will terminate the app prematurely. Either at the first breakpoint, or when the kernel reaches the int3. (I only tested the latter, as I can not get to the former).
« Last Edit: July 02, 2020, 09:14:08 pm by Martin_fr »

BrunoK

  • Sr. Member
  • ****
  • Posts: 452
  • Retired programmer
Re: int 3 / fpdebug
« Reply #7 on: July 03, 2020, 09:01:46 am »

nanobit

  • Full Member
  • ***
  • Posts: 154
Re: int 3 / fpdebug
« Reply #8 on: July 03, 2020, 10:17:53 am »
My understanding is, debuggers have input (int3, int 3) and output (int3).
And the decision needed is only about the input side, how many opcodes does the debugger accept.
If I read "Intel and Microsoft assemblers will not generate the CD03 opcode from any mnemonic",
then the 2-byte version does not seem to have many use cases, and now the most common use case
is that users write such asm block without the specific intention that it should produce CD03.
My conclusion: Support of 2-byte version could be dispensable.

Added: I found some interesting mnemonic difference:
Delphi does not understand "asm int3 end;"
but the 1-byte opcode (CC) is produced with "asm int 3 end;"
« Last Edit: July 03, 2020, 05:55:14 pm by nanobit »

 

TinyPortal © 2005-2018