FpDebug unexpected Assembly window upon 32bit program start.

[440bx]

This is the bug thread related to the post https://forum.lazarus.freepascal.org/index.php/topic,66143.msg513958.html#msg513958

Attached is the source of a program that compiles in both 32 and 64 bit. 

When compiled in 32bit and pressing F9 to execute the code, the assembly window opens and it takes pressing F9 again for the executable to start running.

This does not happen in 64bit.  In 64bit everything takes places as expected (no assembly window and no having to press F9 a second time.)

On a different note:

This is the source for a little utility I use to select colors.  The window shows RGB colors against a black background (which can be changed by editing the source), this allows selecting multiple colors that can be easily distinguished visually, i.e, avoid having two shades of a color that are so similar that it's not readily apparent that they are not the same color.

There are three pages, double clicking on the client area shows the next page and wraps around back to the first page when needed.   The window can be moved by simply pressing the left mouse button on the client area and dragging it around (IOW, no need to go to the title bar... saves a lot of mouse miles... protects the mouse's resell value)

[Martin_fr]

Can you confirm, that you always use a 64 bit IDE, and only the target changes between 32 and 64 bit? I.e., the 32 bit version is being cross-debugged?

[440bx]

Can you confirm, that you always use a 64 bit IDE, and only the target changes between 32 and 64 bit? I.e., the 32 bit version is being cross-debugged?

Yes, I can confirm that.  The IDE is 64bit and only the target/bitness changes between compiles.

[Martin_fr]

I did some tests and I think it is "correct" behaviour.

Btw, there is one other report I could find that has the same issue (albeit 64bit) https://forum.qt.io/topic/146496/qt-creator-debugger-stops-at-ldrinitshimenginedynamic/4
which stops at an "int3" in ntdll:LdrInitShimEngineDynamic

That int3 is there, for whatever reason Windows put it there.
The issue only occurs (to me) if I configure FpDebug to stop at hardcoded int3.

I can set a breakpoint at the instruction before the int3, and it will be reached during startup of the app.

Googling "ntdll shim engine" brings up some reference that explain this is setting up a Windows API (kind of wrapper) so the OS acts according to the apps manifest, and other app related settings/data. => In other words, normal that the code (some shim related code) is run.

It also means it is quite plausible that different shim code is run, depending on
- the apps bitness
- a debugger present
- the debugger doing cross-bitness debugging (because certain events a reported differently to the debugger)

Which would explain why this only happens in this 32 bit cross debugging case.

With GDB you don't normally cross debug. If correctly setup, then for 32 bit debugging (under a 64 bit IDE) there is a 32bit gdb.exe. And if the gdb.exe is 32bit => then it is not cross debugging.
And iirc many versions of gdb have issues cross debugging....

But I tried with gdb 12 (latest I currently have on Windows) as 64bit gdb.
I had to run it outside the IDE => and then it stopped at the int3 too. I am not sure why it didn't when run from the IDE (but then the IDE does a ton of setup) to gdb.

[Martin_fr]

And, yes: It would be possible to add "smartness" to FpDebug, to only stop at certain hardcode int3.
But that is currently not on the "anytime soon" list.

[440bx]

That int3 is there, for whatever reason Windows put it there.
The issue only occurs (to me) if I configure FpDebug to stop at hardcoded int3.

That makes perfect sense.  I am embarrassed to admit that I was so focused on my code that I didn't notice the int 3. 

However, I stepped through the assembly code and the execution flow quickly becomes illogical, i.e, an instruction "push $01" starts the program.  I expected reaching the program's entry point using either a call through a register or a jump but not a "push $01".

And, yes: It would be possible to add "smartness" to FpDebug, to only stop at certain hardcode int3.
But that is currently not on the "anytime soon" list.

I think the current solution/behavior is fine.  The only thing I'd like is to see CD 03 be treated like CC is (I put a request for that in the bug tracker and I know you've seen it... no rush... DebugBreak() works great )

[Martin_fr]

Are you stepping with normal F8?

I just tested => that indeed misbehaves. It appears to do "step out".


F8 normally needs source line info, so it knows when it stepped over the line.
If there is no source info, it should do an asm statement step.

I guess that it somehow mistakes the library entry point names as line info. And then that only changes when it steps out.


That should be bug reported.

[440bx]

Are you stepping with normal F8?

Yes, I tried it with both F7 and F8, got "weird" execution with either one.

If there is no source info, it should do an asm statement step.

I guess the debugger gets "lost" when/if there is no DWARF info available for the line,  (which in that case there isn't).

That should be bug reported.

Will do.  Will reference this thread in the report.

By the way and, just FYI, I no longer use GDB, I'm doing all the debugging with FpDebug, I find it much more usable than GDB.  That said, I tend to use v3.2, I should use v3.99 a little more (got v3.2 more "finely" configured than v3.99)

ETA:

Issue: #40891

[Martin_fr]

I think Alt-F7/F8 are mapped to asm-stepping. But better check the keymap, if you need those.

[440bx]

I think Alt-F7/F8 are mapped to asm-stepping. But better check the keymap, if you need those.

I didn't realize that Alt-F7/F8 were mapped to asm stepping.  I just checked and, they are.

I expected F7 and F8 to be context sensitive, that is, if the Assembly window is focused then F7 and F8 apply to it.  As it is, F7 and F8 do work (they do something) in the assembly window but, I'm not quite sure how they are supposed to operate. I guess the same as their "Alt" counterpart ?

[Martin_fr]

I think Alt-F7/F8 are mapped to asm-stepping. But better check the keymap, if you need those.

I didn't realize that Alt-F7/F8 were mapped to asm stepping.  I just checked and, they are.

I expected F7 and F8 to be context sensitive, that is, if the Assembly window is focused then F7 and F8 apply to it.  As it is, F7 and F8 do work (they do something) in the assembly window but, I'm not quite sure how they are supposed to operate. I guess the same as their "Alt" counterpart ?

I don't think they are context sensitive by default. But you can remap that. There are 3 pairs of Step-In/Over
- Source, always
- ASM, always
- context on focused window

However, "Source Always" should asm step, if no source info is available (but that is broken...). However if source code is available, and you open the asm and focus it, then they should still step the entire source line (the asm window shows source lines too)

[440bx]

I'll play with those key assignments (F7/F8 and their Alt counterparts) once they work properly.

[Marc]

However if source code is available, and you open the asm and focus it, then they should still step the entire source line (the asm window shows source lines too)

From what I used to in delphi: F7 steps source when it has focus. when the asm has focus F7 steps there.
There is a reason I focused the asm window, so I want to step there. I always have found the lazarus way a pain, but never took the time to "fix" it. I see no reason the have different keys for it.

[Martin_fr]

There already is a command that does exactly this "focused behaviour"

Any user can go to there keymap, and reassign F7/F8 to the focus sensitive command.

https://wiki.freepascal.org/IDE_Window:_Assembler#Using_the_same_or_different_keys_for_Pascal_and_ASM_stepping

Assign F7/F8 to the marked entries of the keymap

[ccrause]

From what I used to in delphi: F7 steps source when it has focus. when the asm has focus F7 steps there.
There is a reason I focused the asm window, so I want to step there. I always have found the lazarus way a pain, but never took the time to "fix" it. I see no reason the have different keys for it.

There already is a command that does exactly this "focused behaviour"

Thank you for the tip, this was also an annoyance for me.