Testers for GDB Based debugger / Windows / Lazarus SVN

Forum > Lazarus

(1/5) > >>

Martin_fr:
Looking for testers for some updates to the GDB based debugger.

Anyone using Lazarus SVN on Windows (64 or 32 bit)

* Testing the current GDB (includes users on all other OS - if gdb is used)
- please update to rev 64877 or later
Ensure all works as before.

* Testing the **NEW** GDB
- please update to rev 64877 or later
- Download the new version of GDB (and cygwin1.dll) from
32Bit: https://sourceforge.net/projects/lazarus/files/Lazarus%20Windows%2032%20bits/Alternative%20GDB/GDB%209.2/
64Bit: https://sourceforge.net/projects/lazarus/files/Lazarus%20Windows%2064%20bits/Alternative%20GDB/GDB%209.2/

- Place GDB exe and cygwin1.dll in a new Folder.
- Tools > Options > Debugger Backend
Choose the new gdb.exe

What are the changes.

The new version of GDB supports Unicode for
- Environment (any existing, as well as any env-var set under "Run > Run Param" can now contain Unicode)
- Command line arguments "Run > Run Param"
- Hopefully the Path of the current dir, and the exe name (though the latter is limited by what FPC can generate)
This does/should not affect inspecting variables, even if the contain Unicode.

All else should work as before.

Since the new gdb has a habit of showing directories as /cygdrive/c/path, the IDE now has code to correct that. Look out, if "/cygdrive/" is displayed anywhere by the debugger.

Thanks

MarkMLl:
Just upgraded to 64877 with FPC 3.2.0 on Debian 64-bit, will keep an eye open for anything unexpected.

MarkMLl

ASerge:
Win64.
It looks like the TGDBMIDebuggerBase.ConvertToGDBPath function does something wrong in trunk.
TGDBMIDebuggerCommandStartDebugging.DoExecute do:

--- Code: Pascal [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} --- if FTheDebugger.WorkingDir <> '' then begin // to workaround a possible bug in gdb, first set the workingdir to . // otherwise on second run within the same gdb session the workingdir // is set to c:\windows ExecuteCommand('-environment-cd %s', ['.'], []); ExecuteCommand('-environment-cd %s', [FTheDebugger.ConvertToGDBPath(FTheDebugger.WorkingDir, cgptCurDir)], [cfCheckError]); end;The first ExecuteCommand is executed successfully. Second in release 2.0.12 executed successfully, but in trunk 64877 issues '-environment-cd' without path. As result GDB stop with error. From log:

--- Code: Text [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---(gdb) <-environment-cd .>^done(gdb) <-environment-cd >^error,msg="-environment-cd: Usage DIRECTORY"(gdb) <kill>

Martin_fr:
Indeed, uninitialized var.

Fixed in 64880

MarkMLl:

--- Quote from: Martin_fr on March 28, 2021, 03:26:30 pm ---Indeed, uninitialized var.

Fixed in 64880

--- End quote ---

Same problem on Debian, fixed as you expected.

MarkMLl

Navigation

[0] Message Index

[#] Next page