Recent

Author Topic: Testers for GDB Based debugger / Windows / Lazarus SVN  (Read 4553 times)

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 7095
  • Debugger - SynEdit - and more
    • wiki
Testers for GDB Based debugger / Windows / Lazarus SVN
« on: March 28, 2021, 03:03:18 am »
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

  • Hero Member
  • *****
  • Posts: 2529
Re: Testers for GDB Based debugger / Windows / Lazarus SVN
« Reply #1 on: March 28, 2021, 09:46:21 am »
Just upgraded to 64877 with FPC 3.2.0 on Debian 64-bit, will keep an eye open for anything unexpected.

MarkMLl
Turbo Pascal v1 on CCP/M-86, multitasking with LAN and graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

ASerge

  • Hero Member
  • *****
  • Posts: 1781
Re: Testers for GDB Based debugger / Windows / Lazarus SVN
« Reply #2 on: March 28, 2021, 10:28:23 am »
Win64.
It looks like the TGDBMIDebuggerBase.ConvertToGDBPath function does something wrong in trunk.
TGDBMIDebuggerCommandStartDebugging.DoExecute do:
Code: Pascal  [Select][+][-]
  1.     if FTheDebugger.WorkingDir <> ''
  2.     then begin
  3.       // to workaround a possible bug in gdb, first set the workingdir to .
  4.       // otherwise on second run within the same gdb session the workingdir
  5.       // is set to c:\windows
  6.       ExecuteCommand('-environment-cd %s', ['.'], []);
  7.       ExecuteCommand('-environment-cd %s', [FTheDebugger.ConvertToGDBPath(FTheDebugger.WorkingDir, cgptCurDir)], [cfCheckError]);
  8.     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  [Select][+][-]
  1. (gdb)
  2. <-environment-cd .>
  3. ^done
  4. (gdb)
  5. <-environment-cd >
  6. ^error,msg="-environment-cd: Usage DIRECTORY"
  7. (gdb)
  8. <kill>

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 7095
  • Debugger - SynEdit - and more
    • wiki
Re: Testers for GDB Based debugger / Windows / Lazarus SVN
« Reply #3 on: March 28, 2021, 03:26:30 pm »
Indeed, uninitialized var.

Fixed in 64880

MarkMLl

  • Hero Member
  • *****
  • Posts: 2529
Re: Testers for GDB Based debugger / Windows / Lazarus SVN
« Reply #4 on: March 28, 2021, 05:39:02 pm »
Indeed, uninitialized var.

Fixed in 64880

Same problem on Debian, fixed as you expected.

MarkMLl
Turbo Pascal v1 on CCP/M-86, multitasking with LAN and graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

Red_prig

  • New member
  • *
  • Posts: 7
Re: Testers for GDB Based debugger / Windows / Lazarus SVN
« Reply #5 on: April 16, 2021, 08:58:42 pm »
Why use cygwin at all if cross compilation works well? In addition, the 10th version of the gdb has already been released. Here are the scripts for cross-compilation not difficult at all:
https://github.com/red-prig/cross-build/tree/master/gdb-9.2
https://github.com/red-prig/cross-build/tree/master/gdb-10.1

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 7095
  • Debugger - SynEdit - and more
    • wiki
Re: Testers for GDB Based debugger / Windows / Lazarus SVN
« Reply #6 on: April 16, 2021, 09:41:36 pm »
GDB 10.1 compiled for windows causes an error. It hits an assertion when the IDE send "ptype shortstring" (or maybe it was "whatis shortstring").

The IDE sends a few test "ptype" at startup, to gather some info it needs to deal with different behaviours by gdb/fpc/debug-info variations. So this error happens even before the debugging starts.
I changed the IDE not to send this, but there may be other data, that may hit this new assertion.

Therefore for now its 9.2.


cygwin:

This is the only way to build gdb (without modifying it) to support Unicode environment and command line args to the debugged app..

GDB build without cygwin do not support Unicode environment (I checked that in the gdb source).
Also IIRC they do not support unicode for command line args (that one is from testing /trial and error).

This limitation can cause debugging to fail, if some environment (even just the defaults / does not have to be set by the IDE) would have none a-z letters (like a path including the username, if that username has special chars).

Well, the old 7.3.5 64bit gdb was none cygwin. And did not cause the problem. This was because that gdb would not set any custom environment at all. But that means "run parameters" env would not work.

The cygwin builds deal with that.

That said, the IDE supports none cygwin builds too, if you can live with not having Unicode in the env.
But for packaging into the installer, the gdb should support this.
Hence I would like test results with that cygwin build. So issues will be known before it is added to a release.




Red_prig

  • New member
  • *
  • Posts: 7
Re: Testers for GDB Based debugger / Windows / Lazarus SVN
« Reply #7 on: April 16, 2021, 10:39:36 pm »
Well, I understand, maybe I'll try to modify the gdb for correct environment support.
And if honestly I just do not like cygwin.

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 9280
  • FPC developer.
Re: Testers for GDB Based debugger / Windows / Lazarus SVN
« Reply #8 on: April 16, 2021, 10:40:05 pm »
The problem with delivering a cygwin dll is that it conflicts with an existing cygwin install. IIRC the dlls  communicate over a shared memory area.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 7095
  • Debugger - SynEdit - and more
    • wiki
Re: Testers for GDB Based debugger / Windows / Lazarus SVN
« Reply #9 on: April 17, 2021, 12:39:50 am »
The problem with delivering a cygwin dll is that it conflicts with an existing cygwin install. IIRC the dlls  communicate over a shared memory area.

Not exactly: https://cygwin.com/faq/faq.html#faq.using.multiple-copies
So long as ours is in its own directory, and that it is.

I'd rather have a gdb without libs. But CygWin does not provide for that.
Next best thing is start writing our own gdb, and well frankly not going to be done by anyone sitting at my keyboard.

If someone wants to work on gdb, I can point to the file that has the environment stuff.


This is a Windows only issue. And Windows will move to FpDebug.

But gdb support should still be maintained. Gdb currently has much better stack unwinding than FpDebug. And it is needed for cross-debugging (embedded and the like). Though cross debugging, needs the relevant cross gdb, and therefore is not part of this issue either.


Code: Text  [Select][+][-]
  1. GDB has target and host charset: https://sourceware.org/gdb/current/onlinedocs/gdb/Character-Sets.html#Character-Sets
  2. But the code for the arguments/environment does not seem to be dependent on that in any way.
  3. The none cycwin code uses CreateProcessA => and that cannot support anything but the local 8bit charset. (Of course that can be changed to CreateProcess(W), once args have been translated.
  4.  
  5. The file is windows-nat.c  in the gdb subfolder.
  6. I do not know if utf8 content in environment or arguments will cause any issues in other files. But I do not expect it....
  7.  
  8. Lines given as of commit
  9. SHA-1: 1510de429446e47cb01d6030c1c172d71f9d43f6   tag gdb-10.1-release
  10.  
  11. *** line 2370
  12.  
  13. #ifdef __CYGWIN__
  14. static void
  15. clear_win32_environment (char **env)
  16. {
  17. ...
  18.   for (i = 0; env[i] && *env[i]; i++)
  19.     {
  20. ...
  21.       mbstowcs (copy, env[i], len);
  22. ...
  23.       SetEnvironmentVariableW (copy, NULL);
  24. ...
  25. #endif
  26.  
  27. ========================================================
  28.  
  29. *** Line 2755
  30. #ifdef __CYGWIN__
  31.  
  32. *** line 2763 and follow // cygallargs creaeted as utf16 copy of args
  33.       mbstowcs (cygallargs, allargs, len);
  34. ...
  35.   args = (cygwin_buf_t *) alloca ((wcslen (toexec) + wcslen (cygallargs) + 2)
  36.                   * sizeof (wchar_t));
  37.   wcscpy (args, toexec);
  38.   wcscat (args, L" ");
  39.   wcscat (args, cygallargs);
  40.  
  41.  
  42. *** line 2811 // convert env to utf16 / the CREATE_UNICODE_ENVIRONMENT flag is important
  43.  
  44. #ifdef CW_CVT_ENV_TO_WINENV
  45.   /* First try to create a direct Win32 copy of the POSIX environment. */
  46.   w32_env = (PWCHAR) cygwin_internal (CW_CVT_ENV_TO_WINENV, in_env);
  47.   if (w32_env != (PWCHAR) -1)
  48.     flags |= CREATE_UNICODE_ENVIRONMENT;
  49.   else
  50.     /* If that fails, fall back to old method tweaking GDB's environment. */
  51. #endif    /* CW_CVT_ENV_TO_WINENV */
  52.     {
  53.       /* Reset all Win32 environment variables to avoid leftover on next run. */
  54.       clear_win32_environment (environ);
  55.  
  56.  
  57. *** line 2851  this is   ret = CreateProcessW
  58.   ret = CreateProcess (0,
  59.  
  60.  
  61. ===============================================
  62. *** line 2884   // the none cygwin code
  63. #else  /* !__CYGWIN__ */
  64.  
  65. *** line 2975  // the locale encoding CreateProcessA
  66.   ret = CreateProcessA (0,
  67.  
  68.  



As for testing, their is a testcase in the components/lazdebuggergdbmi/test folder.
See the 2 sample files how to create the correct config.
Create a logs folder and TestApps/lib

Then you can run it.

Download *all* the gdb from our sourceforge "Alternative GDB" (both 32 and 64 bit), so you can test with all of them. (People may have older gdb for cross debug, or on older Linux / Though Linux needs to be tested with gdb on Linux too)

Also test at least with Fpc 3.2  / 3.2.2  / trunk and maybe 3.0.4 (It is still used).
I even occasionally test with 3.0, and 2.6.4

There are a few tests currently failing (using dwarf2 with/without sets).
Dwarf3 is still a mine field of failures, and even gdb crashes.
« Last Edit: April 17, 2021, 12:53:13 am by Martin_fr »

Red_prig

  • New member
  • *
  • Posts: 7
Re: Testers for GDB Based debugger / Windows / Lazarus SVN
« Reply #10 on: April 17, 2021, 06:57:36 pm »
I set exe name on non ASCI:  "Проект.exe". cygwin version gdb is crash for:
Quote
G:/Github/testgdb/317360356345352362.exe: No such file or directory.
Also tests showed that the cygwin version does not transmit parameters from lazarus. (system.ParamStr (1) is always empty) I'm not a cygwin version, oddly enough, it correctly passes parameters but corrupt the encoding of the environment. (Lazarus is stable 2.0.12)

Red_prig

  • New member
  • *
  • Posts: 7
Re: Testers for GDB Based debugger / Windows / Lazarus SVN
« Reply #11 on: April 17, 2021, 07:22:58 pm »
Also an interesting question is whether gdb changes the parameters of the environment? Maybe you should pass the lpEnvironment = NULL parameter to CreateProcessA/CreateProcessW, passing them unchanged?

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 7095
  • Debugger - SynEdit - and more
    • wiki
Re: Testers for GDB Based debugger / Windows / Lazarus SVN
« Reply #12 on: April 17, 2021, 07:31:57 pm »
I set exe name on non ASCI:  "Проект.exe". cygwin version gdb is crash for:
Quote
G:/Github/testgdb/317360356345352362.exe: No such file or directory.
Also tests showed that the cygwin version does not transmit parameters from lazarus. (system.ParamStr (1) is always empty) I'm not a cygwin version, oddly enough, it correctly passes parameters but corrupt the encoding of the environment. (Lazarus is stable 2.0.12)
You need Lazarus trunk to support this.

If you find a case, that works in the old, but not the new gdb, then please attach logs for both runs.
https://wiki.lazarus.freepascal.org/GDB_Debugger_Tips#Log_info_for_debug_session

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 7095
  • Debugger - SynEdit - and more
    • wiki
Re: Testers for GDB Based debugger / Windows / Lazarus SVN
« Reply #13 on: April 17, 2021, 07:33:35 pm »
Also an interesting question is whether gdb changes the parameters of the environment? Maybe you should pass the lpEnvironment = NULL parameter to CreateProcessA/CreateProcessW, passing them unchanged?
Yes it does. Look at the sources I pointed out.

Except the 7.3.5 build that we have. That leaves the environment unchanged. Not sure why.

Red_prig

  • New member
  • *
  • Posts: 7
Re: Testers for GDB Based debugger / Windows / Lazarus SVN
« Reply #14 on: April 17, 2021, 10:10:05 pm »
Analysis of the source code showed just a huge number of places where a transform oem to Unicode is needed.  >:(
It is probably even easier to use cygwin, or to emulate the cygwin itself.

 

TinyPortal © 2005-2018