[1/4] Fix calling convention of thread entry point

Message ID 20221128191224.1411-1-ssbssa@yahoo.de
State Committed
Commit 1d39fec4aeacc53f6eb696eaa846f8f07948fcf5
Headers
Series [1/4] Fix calling convention of thread entry point |

Commit Message

Hannes Domani Nov. 28, 2022, 7:12 p.m. UTC
  For i686 the CreateThread entry point function needs the WINAPI (stdcall)
calling convention:

../../gdb/windows-nat.c: In constructor 'windows_nat_target::windows_nat_target()':
../../gdb/windows-nat.c:450:56: error: invalid user-defined conversion from 'windows_nat_target::windows_nat_target()::<lambda(LPVOID)>' to 'LPTHREAD_START_ROUTINE' {aka 'long unsigned int (__attribute__((stdcall)) *)(void*)'} [-fpermissive]
  450 |   HANDLE bg_thread = CreateThread (nullptr, 64 * 1024, fn, this, 0, nullptr);
      |                                                        ^~
../../gdb/windows-nat.c:444:13: note: candidate is: 'constexpr windows_nat_target::windows_nat_target()::<lambda(LPVOID)>::operator DWORD (*)(LPVOID)() const' (near match)
  444 |   auto fn = [] (LPVOID self) -> DWORD
      |             ^
../../gdb/windows-nat.c:444:13: note:   no known conversion from 'DWORD (*)(LPVOID)' {aka 'long unsigned int (*)(void*)'} to 'LPTHREAD_START_ROUTINE' {aka 'long unsigned int (__attribute__((stdcall)) *)(void*)'}

Since it's not possible to change the calling convention of a lambda, I've
moved it to a separate function.
---
 gdb/windows-nat.c | 19 ++++++++++++-------
 1 file changed, 12 insertions(+), 7 deletions(-)
  

Comments

Tom Tromey Nov. 28, 2022, 7:24 p.m. UTC | #1
>>>>> "Hannes" == Hannes Domani via Gdb-patches <gdb-patches@sourceware.org> writes:

Hannes> For i686 the CreateThread entry point function needs the WINAPI (stdcall)
Hannes> calling convention:

Thanks, this is ok.

I don't know why, but I don't see this when building on a Windows
machine here.  However, I can reproduce it using the mingw cross
toolchain on Fedora.

Tom
  
Hannes Domani Nov. 28, 2022, 7:45 p.m. UTC | #2
Am Montag, 28. November 2022, 20:24:51 MEZ hat Tom Tromey <tom@tromey.com> Folgendes geschrieben:

> >>>>> "Hannes" == Hannes Domani via Gdb-patches <gdb-patches@sourceware.org> writes:
>
> Hannes> For i686 the CreateThread entry point function needs the WINAPI (stdcall)
> Hannes> calling convention:
>
> Thanks, this is ok.
>
> I don't know why, but I don't see this when building on a Windows
> machine here.  However, I can reproduce it using the mingw cross
> toolchain on Fedora.

Thanks, I've pushed these 4 patches.


Hannes
  

Patch

diff --git a/gdb/windows-nat.c b/gdb/windows-nat.c
index 5d506507b6d..f61f6c1cb35 100644
--- a/gdb/windows-nat.c
+++ b/gdb/windows-nat.c
@@ -344,6 +344,9 @@  struct windows_nat_target final : public x86_nat_target<inf_child_target>
   BOOL windows_continue (DWORD continue_status, int id, int killed,
 			 bool last_call = false);
 
+  /* Helper function to start process_thread.  */
+  static DWORD WINAPI process_thread_starter (LPVOID self);
+
   /* This function implements the background thread that starts
      inferiors and waits for events.  */
   void process_thread ();
@@ -404,13 +407,8 @@  windows_nat_target::windows_nat_target ()
     m_response_event (CreateEvent (nullptr, false, false, nullptr)),
     m_wait_event (make_serial_event ())
 {
-  auto fn = [] (LPVOID self) -> DWORD
-    {
-      ((windows_nat_target *) self)->process_thread ();
-      return 0;
-    };
-
-  HANDLE bg_thread = CreateThread (nullptr, 64 * 1024, fn, this, 0, nullptr);
+  HANDLE bg_thread = CreateThread (nullptr, 64 * 1024,
+				   process_thread_starter, this, 0, nullptr);
   CloseHandle (bg_thread);
 }
 
@@ -453,6 +451,13 @@  wait_for_single (HANDLE handle, DWORD howlong)
     }
 }
 
+DWORD WINAPI
+windows_nat_target::process_thread_starter (LPVOID self)
+{
+  ((windows_nat_target *) self)->process_thread ();
+  return 0;
+}
+
 void
 windows_nat_target::process_thread ()
 {