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-copiesSo 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.
GDB has target and host charset: https://sourceware.org/gdb/current/onlinedocs/gdb/Character-Sets.html#Character-Sets
But 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 commit
SHA-1: 1510de429446e47cb01d6030c1c172d71f9d43f6 tag gdb-10.1-release
*** line 2370
#ifdef __CYGWIN__
static void
clear_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.
Recent
