Author Topic: debugger plugin: catch the inferior PID under gdb  (Read 36217 times)

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5915
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
debugger plugin: catch the inferior PID under gdb
« on: April 05, 2012, 05:06:44 am »
Code
void GDB_driver::ParseOutput(const wxString& output)
{
    m_Cursor.changed = false;

    // Watch for initial debug info and grab the child PID
    // this is put here because we need this info even if
    // we don't get a prompt back.
    // It's "cheap" anyway because the line we 're after is
    // the very first line printed by gdb when running our
    // program. It then sets the child PID and never enters here
    // again because the "want_debug_events" condition below
    // is not satisfied anymore...
    if (platform::windows && want_debug_events)
    {
        wxRegEx* re = 0;
        if ((m_GDBVersionMajor > 6 || (m_GDBVersionMajor == 6 && m_GDBVersionMinor >= 7)) &&
            output.Contains(_T("CREATE_PROCESS_DEBUG_EVENT")))
        {
            re = &reChildPid2;
        }
        else if (m_GDBVersionMajor <= 6 && output.Contains(_T("do_initial_child_stuff")))
            re = &reChildPid;
        else if (m_attachedToProcess)
            re = &reAttachedChildPid;

        if (re)
        {
            // got the line with the PID, parse it out:
            // e.g.
            // gdb: do_initial_child_stuff: process 1392
            if (re->Matches(output))
            {
                wxString pidStr = re->GetMatch(output, 1);
                long pid = 0;
                pidStr.ToLong(&pid);
                SetChildPID(pid);
                want_debug_events = false;
                disable_debug_events = true;
                m_pDBG->Log(wxString::Format(_("Child process PID: %d"), pid));
            }
        }
    }
    else if (!platform::windows && m_ChildPID == 0)
    {
        if (reChildPid3.Matches(output)) // [Switching to Thread -1234655568 (LWP 18590)]
        {
            wxString pidStr = reChildPid3.GetMatch(output, 1);
            long pid = 0;
            pidStr.ToLong(&pid);
            SetChildPID(pid);
            m_pDBG->Log(wxString::Format(_("Child process PID: %d"), pid));
        }
    }

    if (!want_debug_events &&
        (output.StartsWith(_T("gdb: ")) ||
        output.StartsWith(_T("Warning: ")) ||
        output.StartsWith(_T("ContinueDebugEvent "))))
    {
        return;
    }

    static wxString buffer;
    buffer << output << _T('\n');

    m_pDBG->DebugLog(output);

    int idx = buffer.First(GDB_PROMPT);
    if (idx == wxNOT_FOUND)
    {
        // don't uncomment the following line
        // m_ProgramIsStopped is set to false in DebuggerDriver::RunQueue()
//        m_ProgramIsStopped = false;
        return; // come back later
    }

    if (disable_debug_events)
    {
        // we don't want debug events anymore (we got the pid)
        QueueCommand(new DebuggerCmd(this, _T("set debugevents off")));
        disable_debug_events = false;
    }

Here is the code to parse gdb output.
To catch the PID, we have different methods:
Under Windows, we need first "set debugevents on", and if we receive some message matches "CREATE_PROCESS_DEBUG_EVENT", then we get the PID, and send: "set debugevents off".

Under Linux, it is quite simple, just matches the message "[Switching to Thread -1234655568 (LWP 18590)]"

When I debug under Windows gdb, I see some message:

Code
Debugger name and version: GNU gdb (GDB) 7.4.50.20120331-cvs

[debug]>>>>>>cb_gdb:
[debug]> set width 0
[debug]>>>>>>cb_gdb:
[debug]> set height 0
[debug]>>>>>>cb_gdb:
[debug]> set breakpoint pending on
[debug]>>>>>>cb_gdb:
[debug]> set print asm-demangle on
[debug]>>>>>>cb_gdb:
[debug]> set unwindonsignal on
[debug]>>>>>>cb_gdb:
[debug]> set print elements 0
[debug]>>>>>>cb_gdb:
[debug]> set debugevents on
[debug]>>>>>>cb_gdb:
[debug]> set disassembly-flavor att
[debug]>>>>>>cb_gdb:
[debug]> catch throw
[debug]Catchpoint 1 (throw)
[debug]>>>>>>cb_gdb:
[debug]> source E:\code\gcc\PCXMinGW463\\bin\my.gdb
[debug]>>>>>>cb_gdb:
[debug]> directory E:/code/cb/test_code/IsAlpha/
[debug]Source directories searched: E:/code/cb/test_code/IsAlpha;$cdir;$cwd
[debug]>>>>>>cb_gdb:
[debug]> break "E:/code/cb/test_code/IsAlpha/IsAlphaMain.cpp:114"
[debug]Breakpoint 2 at 0x401f5c: file E:\code\cb\test_code\IsAlpha\IsAlphaMain.cpp, line 114.
[debug]>>>>>>cb_gdb:
[debug]> break "E:/code/cb/test_code/IsAlpha/IsAlphaMain.cpp:106"
[debug]Breakpoint 3 at 0x401e6b: file E:\code\cb\test_code\IsAlpha\IsAlphaMain.cpp, line 106.
[debug]>>>>>>cb_gdb:
[debug]> run
[debug]Starting program: E:\code\cb\test_code\IsAlpha\bin\Debug\IsAlpha.exe
[debug]gdb: windows_init_thread_list

Child process PID: 2684

[debug][New Thread 2684.0xf40]
[debug]Breakpoint 3, IsAlphaFrame::OnAbout (this=0xb66da0, event=...) at E:\code\cb\test_code\IsAlpha\IsAlphaMain.cpp:106
[debug]E:\code\cb\test_code\IsAlpha\IsAlphaMain.cpp:106:3032:beg:0x401e6b
[debug]>>>>>>cb_gdb:

At E:\code\cb\test_code\IsAlpha\IsAlphaMain.cpp:106

[debug]> set debugevents off
[debug]>>>>>>cb_gdb:

There are two point:
1, the set debugevents off command is send only after the first bp meet.
2, there are some message "[New Thread 2684.0xf40]", and this 2684 is just the PID, so can we simplify use this info to get PID?
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: debugger plugin: catch the inferior PID under gdb
« Reply #1 on: April 05, 2012, 06:32:43 am »
2, there are some message "[New Thread 2684.0xf40]", and this 2684 is just the PID, so can we simplify use this info to get PID?
If this also works with older, but wide spread debuggers (6.8) and also in other cases like attaching to a process for example - why not?
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5915
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: debugger plugin: catch the inferior PID under gdb
« Reply #2 on: April 05, 2012, 06:48:42 am »
2, there are some message "[New Thread 2684.0xf40]", and this 2684 is just the PID, so can we simplify use this info to get PID?
If this also works with older, but wide spread debuggers ( 6.8 ) and also in other cases like attaching to a process for example - why not?
I will test 6.8 version and give feedback.

I have never use "attaching a process" in c::b debugger plugin. But for this feature (I see it under "Debug" menu), we need to manually enter a PID number.



If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5915
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: debugger plugin: catch the inferior PID under gdb
« Reply #3 on: April 05, 2012, 07:07:32 am »
Ok, I just download this one:
gdb-6.8-mingw-3.tar.bz2

And it do have the same log:

Code
[debug]gdb: win32_init_thread_list

Child process PID: 1748

[debug][New thread 1748.0x1300]
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: debugger plugin: catch the inferior PID under gdb
« Reply #4 on: April 05, 2012, 07:24:02 am »
Did you also test it with non-threaded application (simple hello world example should do it) ?
I don't get any such message here on linux in this case.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: debugger plugin: catch the inferior PID under gdb
« Reply #5 on: April 05, 2012, 08:18:53 am »
If it was that simple it would have been so easy, but this output is meant for people not IDEs, so it is random and not consistent.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5915
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: debugger plugin: catch the inferior PID under gdb
« Reply #6 on: April 05, 2012, 12:49:14 pm »
Did you also test it with non-threaded application (simple hello world example should do it) ?
My original test was a wxWidgets app(single thread), now I test a single thread hello world console app, both of them show the correct message that I needed.

Quote
I don't get any such message here on linux in this case.
If you look at the original post's code snippet, you can see
Code
    else if (!platform::windows && m_ChildPID == 0)
    {
        if (reChildPid3.Matches(output)) // [Switching to Thread -1234655568 (LWP 18590)]
        {
            wxString pidStr = reChildPid3.GetMatch(output, 1);
            long pid = 0;
            pidStr.ToLong(&pid);
            SetChildPID(pid);
            m_pDBG->Log(wxString::Format(_("Child process PID: %d"), pid));
        }
    }
This means, under Linux, it use reChildPid3, which is defined as:
Code
// [Switching to Thread -1234655568 (LWP 18590)]
// [New Thread -1234655568 (LWP 18590)]
static wxRegEx reChildPid3(_T("Thread[ \t]+[xA-Fa-f0-9-]+[ \t]+\\(LWP ([0-9]+)\\)]"));

So, as a conclusion, under Linux we don't need some kind of tricks (set on debugevents and later set off debugevents).

@obf:
I tested under Windows, both gdb 6.8 and gdb 7.4 show the PID correctly under the message pattern like:
Code
[New thread 1748.0x1300]
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: debugger plugin: catch the inferior PID under gdb
« Reply #7 on: April 05, 2012, 12:52:50 pm »
ollydbg: Patches welcome, but please wait for 2-3 days until we do the merge...

And Jens is correct because gdb doesn't always print the threading notifications, but if it works on windows I have nothing against it.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5915
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: debugger plugin: catch the inferior PID under gdb
« Reply #8 on: April 05, 2012, 01:42:55 pm »
ollydbg: Patches welcome, but please wait for 2-3 days until we do the merge...

And Jens is correct because gdb doesn't always print the threading notifications, but if it works on windows I have nothing against it.
Ok, I put this in my TODO list. Also, the patch should be only touch the Windows side (not Linux side).
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5915
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: debugger plugin: catch the inferior PID under gdb
« Reply #9 on: April 10, 2012, 03:24:29 am »
Code
Index: gdb_driver.cpp
===================================================================
--- gdb_driver.cpp (revision 7929)
+++ gdb_driver.cpp (working copy)
@@ -75,6 +75,7 @@
 // [Switching to Thread -1234655568 (LWP 18590)]
 // [New Thread -1234655568 (LWP 18590)]
 static wxRegEx reChildPid3(_T("Thread[ \t]+[xA-Fa-f0-9-]+[ \t]+\\(LWP ([0-9]+)\\)]"));
+static wxRegEx reChildPid4(_T("\\[New [tT]hread[ \t]+[0-9]+\\.[xA-Fa-f0-9-]+\\]"));
 static wxRegEx reAttachedChildPid(wxT("Attaching to process ([0-9]+)"));
 
 static wxRegEx reInferiorExited(wxT("^\\[Inferior[ \\t].+[ \\t]exited normally\\]$"), wxRE_EXTENDED);
@@ -92,8 +93,6 @@
     m_IsStarted(false),
     m_GDBVersionMajor(0),
     m_GDBVersionMinor(0),
-    want_debug_events(true),
-    disable_debug_events(false),
     m_attachedToProcess(false),
     m_catchThrowIndex(-1)
 {
@@ -243,19 +242,6 @@
     // disalbe result string truncations
     QueueCommand(new DebuggerCmd(this, wxString::Format(wxT("set print elements %d"), printElements)));
 
-    // want debug events
-    if(platform::windows)
-    {
-        QueueCommand(new DebuggerCmd(this, _T("set debugevents on")));
-        want_debug_events = true;
-        disable_debug_events = false;
-    }
-    else
-    {
-        want_debug_events = false;
-        disable_debug_events = false;
-    }
-
     if (platform::windows && isConsole)
         QueueCommand(new DebuggerCmd(this, _T("set new-console on")));
 
@@ -750,43 +736,18 @@
 {
     m_Cursor.changed = false;
 
-    // Watch for initial debug info and grab the child PID
-    // this is put here because we need this info even if
-    // we don't get a prompt back.
-    // It's "cheap" anyway because the line we 're after is
-    // the very first line printed by gdb when running our
-    // program. It then sets the child PID and never enters here
-    // again because the "want_debug_events" condition below
-    // is not satisfied anymore...
-    if (platform::windows && want_debug_events)
+    if (platform::windows && m_ChildPID == 0)
     {
-        wxRegEx* re = 0;
-        if ((m_GDBVersionMajor > 6 || (m_GDBVersionMajor == 6 && m_GDBVersionMinor >= 7)) &&
-            output.Contains(_T("CREATE_PROCESS_DEBUG_EVENT")))
+        if (reChildPid4.Matches(output)) // [New Thread 2684.0xf40] or [New thread 2684.0xf40]
         {
-            re = &reChildPid2;
+            wxString pidStr = reChildPid4.GetMatch(output, 0);
+            pidStr = pidStr.BeforeFirst(_T('.')); //[New Thread 2684.0xf40] -> [New Thread 2684
+            pidStr = pidStr.AfterFirst(_T('d')); //[New Thread 2684 ->  2684
+            long pid = 0;
+            pidStr.ToLong(&pid);
+            SetChildPID(pid);
+            m_pDBG->Log(wxString::Format(_("Child process PID: %d"), pid));
         }
-        else if (m_GDBVersionMajor <= 6 && output.Contains(_T("do_initial_child_stuff")))
-            re = &reChildPid;
-        else if (m_attachedToProcess)
-            re = &reAttachedChildPid;
-
-        if (re)
-        {
-            // got the line with the PID, parse it out:
-            // e.g.
-            // gdb: do_initial_child_stuff: process 1392
-            if (re->Matches(output))
-            {
-                wxString pidStr = re->GetMatch(output, 1);
-                long pid = 0;
-                pidStr.ToLong(&pid);
-                SetChildPID(pid);
-                want_debug_events = false;
-                disable_debug_events = true;
-                m_pDBG->Log(wxString::Format(_("Child process PID: %d"), pid));
-            }
-        }
     }
     else if (!platform::windows && m_ChildPID == 0)
     {
@@ -800,10 +761,9 @@
         }
     }
 
-    if (!want_debug_events &&
-        (output.StartsWith(_T("gdb: ")) ||
-        output.StartsWith(_T("Warning: ")) ||
-        output.StartsWith(_T("ContinueDebugEvent "))))
+    if (  output.StartsWith(_T("gdb: "))
+        ||output.StartsWith(_T("Warning: "))
+        ||output.StartsWith(_T("ContinueDebugEvent ")))
     {
         return;
     }
@@ -822,13 +782,6 @@
         return; // come back later
     }
 
-    if (disable_debug_events)
-    {
-        // we don't want debug events anymore (we got the pid)
-        QueueCommand(new DebuggerCmd(this, _T("set debugevents off")));
-        disable_debug_events = false;
-    }
-
     m_QueueBusy = false;
     int changeFrameAddr = 0 ;
     DebuggerCmd* cmd = CurrentCommand();
Index: gdb_driver.h
===================================================================
--- gdb_driver.h (revision 7929)
+++ gdb_driver.h (working copy)
@@ -127,8 +127,6 @@
         long m_GDBVersionMinor;
         wxString flavour;
 
-        bool want_debug_events;
-        bool disable_debug_events;
         bool m_attachedToProcess;
 
         // for remote debugging usage (mainly)

This patch works OK under MinGW GDB6.8 and GDB7.4.

Comments are welcome.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: debugger plugin: catch the inferior PID under gdb
« Reply #10 on: April 10, 2012, 07:56:55 am »
You're very bold in removing the debug events code.
Are you really really sure that gdb will print these messages for every program you start?
What about remote debugging, can you try it?
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5915
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: debugger plugin: catch the inferior PID under gdb
« Reply #11 on: April 10, 2012, 08:24:07 am »
You're very bold in removing the debug events code.
:)

Quote
Are you really really sure that gdb will print these messages for every program you start?
I'm sure at least Windows GDB 6.8-7.4.


Quote
What about remote debugging, can you try it?
I have never used remote debugging. I will try it under WinXP.

BTW:
The debug event on/off feature is a windows only feature implemented in GDB's source file:
Code
gdb\windows-nat.c

It have such code snippet:
Code
#define DEBUG_EVENTS(x)	if (debug_events)	printf_unfiltered x

and: Windows debug event handling.
Code
    case CREATE_PROCESS_DEBUG_EVENT:
      DEBUG_EVENTS (("gdb: kernel event for pid=%d tid=%x code=%s)\n",
    (unsigned) current_event.dwProcessId,
    (unsigned) current_event.dwThreadId,
    "CREATE_PROCESS_DEBUG_EVENT"));
      CloseHandle (current_event.u.CreateProcessInfo.hFile);
      if (++saw_create != 1)
break;
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5915
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: debugger plugin: catch the inferior PID under gdb
« Reply #12 on: April 10, 2012, 09:34:40 am »
@OBF:
I have finally find that how the
Code
[New Thread 2684.0xf40]
Message come from under Windows.

In GDB top level, there is a function in: "gdb\thread.c"
Code
struct thread_info *
add_thread_with_info (ptid_t ptid, struct private_thread_info *private)
{
  struct thread_info *result = add_thread_silent (ptid);

  result->private = private;

  if (print_thread_events)
    printf_unfiltered (_("[New %s]\n"), target_pid_to_str (ptid));

  annotate_new_thread ();
  return result;
}


The function target_pid_to_str() has different implementation in different target, under Windows, it lowers down to "gdb\windows-nat.c"

Code
/* Convert pid to printable format.  */
static char *
windows_pid_to_str (struct target_ops *ops, ptid_t ptid)
{
  static char buf[80];

  if (ptid_get_tid (ptid) != 0)
    {
      snprintf (buf, sizeof (buf), "Thread %d.0x%lx",
ptid_get_pid (ptid), ptid_get_tid (ptid));
      return buf;
    }

  return normal_pid_to_str (ptid);
}
You see, the "Thread %d.0x%lx", the ptid_get_pid (ptid) value is just the PID.

BTW:
In gdb/thread.c
Code
/* Print notices when new threads are attached and detached.  */
int print_thread_events = 1;
static void
show_print_thread_events (struct ui_file *file, int from_tty,
                          struct cmd_list_element *c, const char *value)
{
  fprintf_filtered (file,
    _("Printing of thread events is %s.\n"),
                    value);
}

This means: the value print_thread_events is enabled by default. That's why we get such message under both Windows and Linux.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: debugger plugin: catch the inferior PID under gdb
« Reply #13 on: April 10, 2012, 10:20:20 am »
This means: the value print_thread_events is enabled by default. That's why we get such message under both Windows and Linux.
This is not 100% true for Linux and some (if not all) versions of gdb-7.xx, if you program doesn't use pthreads, it doesn't print it.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5915
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: debugger plugin: catch the inferior PID under gdb
« Reply #14 on: April 10, 2012, 03:49:08 pm »
This means: the value print_thread_events is enabled by default. That's why we get such message under both Windows and Linux.
This is not 100% true for Linux and some (if not all) versions of gdb-7.xx, if you program doesn't use pthreads, it doesn't print it.
Ok, I'm not quite familiar with Linux, so I may wrong.

I have just did under Windows (gdb.exe, this is the local side and gdbserver.exe, this is the remote target side)

See the log on gdbserver side (remote side)
Code
E:\code\gdb\gdbservertest>gdbserver localhost:777 IsAlphaConsole.exe
Process IsAlphaConsole.exe created; pid = 1804
Listening on port 777
Remote debugging from host 127.0.0.1
48 is a digit
49 is a digit
50 is a digit
51 is a digit
52 is a digit
53 is a digit
54 is a digit
55 is a digit
56 is a digit
57 is a digit
178 is a digit
179 is a digit
185 is a digit

GDB side: (local side)
Code
E:\code\gdb\gdbbin>gdb IsAlphaConsole.exe
GNU gdb (GDB) 7.4.50.20120331-cvs
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from E:\code\gdb\gdbbin\IsAlphaConsole.exe...done.
(gdb) target remote localhost:777
Remote debugging using localhost:777
0x7c90120f in ntdll!DbgUiConnectToDbg () from C:\WINDOWS\system32\ntdll.dll
(gdb) b main
Breakpoint 1 at 0x4016ee: file E:\code\cb\test_code\IsAlphaConsole\main.cpp, lin
e 10.
(gdb) b main.cpp:15
Breakpoint 2 at 0x401753: file E:\code\cb\test_code\IsAlphaConsole\main.cpp, lin
e 15.
(gdb) continue
Continuing.

Breakpoint 1, main () at E:\code\cb\test_code\IsAlphaConsole\main.cpp:10
10          for (i = 0; i < 500; ++i)
(gdb) c
Continuing.

Breakpoint 2, main () at E:\code\cb\test_code\IsAlphaConsole\main.cpp:16
16          for (i = 0; i < 500; ++i)
(gdb)

I'm not sure how Codeblocks catch the PID in the remote side?
It seems that the only interested line is:
Code
Process IsAlphaConsole.exe created; pid = 1804
This is the PID in the remote target. So, my patch does not touch the remote debugging feature in c::b.
See the log when I enable debugevent on in gdb.exe side:
Code
E:\code\gdb\gdbbin>gdb IsAlphaConsole.exe
GNU gdb (GDB) 7.4.50.20120331-cvs
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from E:\code\gdb\gdbbin\IsAlphaConsole.exe...done.
(gdb) set debugevents on
(gdb) target remote localhost:777
Remote debugging using localhost:777
0x7c90120f in ntdll!DbgUiConnectToDbg () from C:\WINDOWS\system32\ntdll.dll
(gdb) b main
Breakpoint 1 at 0x4016ee: file E:\code\cb\test_code\IsAlphaConsole\main.cpp, lin
e 10.
(gdb) b main.cpp:15
Breakpoint 2 at 0x401753: file E:\code\cb\test_code\IsAlphaConsole\main.cpp, lin
e 15.
(gdb) c
Continuing.

Breakpoint 1, main () at E:\code\cb\test_code\IsAlphaConsole\main.cpp:10
10          for (i = 0; i < 500; ++i)
(gdb) c
Continuing.

So, As a conclusion: no PID information about the process in remote side is shown here if I enable debugevents on.




If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.