Forum > Lazarus

Testers for GDB Based debugger / Windows / Lazarus SVN

<< < (2/5) > >>

Red_prig:
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:
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:
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:
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:

--- Quote from: marcov 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.

--- End quote ---

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  [+][-]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 has target and host charset: https://sourceware.org/gdb/current/onlinedocs/gdb/Character-Sets.html#Character-SetsBut the code for the arguments/environment does not seem to be dependent on that in any way.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. The file is windows-nat.c  in the gdb subfolder.I do not know if utf8 content in environment or arguments will cause any issues in other files. But I do not expect it.... Lines given as of commitSHA-1: 1510de429446e47cb01d6030c1c172d71f9d43f6   tag gdb-10.1-release *** line 2370 #ifdef __CYGWIN__static voidclear_win32_environment (char **env){...  for (i = 0; env[i] && *env[i]; i++)    {...      mbstowcs (copy, env[i], len);...      SetEnvironmentVariableW (copy, NULL);...#endif ======================================================== *** Line 2755#ifdef __CYGWIN__ *** line 2763 and follow // cygallargs creaeted as utf16 copy of args      mbstowcs (cygallargs, allargs, len);...  args = (cygwin_buf_t *) alloca ((wcslen (toexec) + wcslen (cygallargs) + 2)                  * sizeof (wchar_t));  wcscpy (args, toexec);  wcscat (args, L" ");  wcscat (args, cygallargs);  *** line 2811 // convert env to utf16 / the CREATE_UNICODE_ENVIRONMENT flag is important #ifdef CW_CVT_ENV_TO_WINENV  /* First try to create a direct Win32 copy of the POSIX environment. */  w32_env = (PWCHAR) cygwin_internal (CW_CVT_ENV_TO_WINENV, in_env);  if (w32_env != (PWCHAR) -1)    flags |= CREATE_UNICODE_ENVIRONMENT;  else    /* If that fails, fall back to old method tweaking GDB's environment. */#endif    /* CW_CVT_ENV_TO_WINENV */    {      /* Reset all Win32 environment variables to avoid leftover on next run. */      clear_win32_environment (environ);  *** line 2851  this is   ret = CreateProcessW  ret = CreateProcess (0,  ===============================================*** line 2884   // the none cygwin code#else  /* !__CYGWIN__ */ *** line 2975  // the locale encoding CreateProcessA  ret = CreateProcessA (0,  
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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version