Re : [gdbserver][WinCE][ARM] gdbserver crash: issue with GetThreadContext???

[Matthieu H <maat_h at yahoo dot fr>]

Many thanks Pedro.

I tested this:

>   char buffer[2048];
>   memset (buffer, 0xaa, sizeof buffer);
>   GetThreadContext (th->h, (CONTEXT *)buffer);
>   // add code that dumps the buffer contents

then printed out the contents of the buffer into a file after the call to 
GetThreadContext.

Surprisingly the contents of the buffer did not changed at all...???
I will double check, but it is very strange :-/

however after this modification, the ptid is not equal to zero: the supposed 
memory corruption does not seems to occurs anymore.

I didnt find the time to investigate more but i will let you know


----- Message d'origine ----
> De : Pedro Alves <pedro@codesourcery.com>
> À : gdb@sourceware.org; Matthieu H <mhameau@yahoo.fr>
> Envoyé le : Ven 11 février 2011, 13h 33min 51s
> Objet : Re: [gdbserver][WinCE][ARM] gdbserver crash: issue with 
>GetThreadContext???
> 
> On Friday 11 February 2011 10:59:29, Matthieu H wrote:
> 
> > /* Fetch  register(s) from the current thread context.  */
> > static  void
> > child_fetch_inferior_registers (struct regcache *regcache, int  r)
> > {
> >   int regno;
> > - win32_thread_info *th =  thread_rec (current_inferior_ptid (), TRUE);
> > + win32_thread_info *th =  thread_rec (current_inferior_ptid (), FALSE);
> > 
> > This tells  gdbserver not to load the context of the thread (=it does not 
>call 
>
> >  GetThreadContext() so "current_inferior" is not corrupted)
> > It's a dirty  workaround cause I believe the thread context is required when 


> >  debugging!
> > But at least I can connect using gdb on my host PC.
> >  The program crash later anyway, I believe the workaround is not good :-)
> > 
> > Can you please help me?
> > Any idea what could be wrong?
> > 
> > GetThreadContext returns value "TRUE", meaning function succeed...  maybe 
> > arguments are wrong... but I'm not expert in gdb enough to say  that.
> 
> Maybe the CONTEXT structure definition in mingw32ce's headers  is
> wrong for this device, and GetThreadContext is thus overwritting
> memory  it shouldn't?  There are a few simple ways to confirm that.
> Try passing  GetThreadContext a big buffer, memset to something
> distinct, like 0xaa, and  check how many bytes does that
> change.  Compare to sizeof  (CONTEXT).  
> 
>   char buffer[2048];
>   memset (buffer,  0xaa, sizeof buffer);
>   GetThreadContext (th->h, (CONTEXT  *)buffer);
>   // add code that dumps the buffer contents, or  counts
>   // how many bytes were changed.
> 
> Another simple check is  to pad the end of win32_thread_info structure
> with extra space.  Notice  that the `context' field is the last of
> the structure:
> 
> /* Thread  information structure used to track extra information about
>    each  thread.  */
> typedef struct win32_thread_info
> {
>   /* The Win32  thread identifier.  */
>   DWORD tid;
> 
>   /* The handle to  the thread.  */
>   HANDLE h;
> 
>   /* Thread Information  Block address.  */
>   CORE_ADDR thread_local_base;
> 
>   /*  Non zero if SuspendThread was called on this thread.  */
>   int  suspended;
> 
> #ifdef _WIN32_WCE
>   /* The context as retrieved right  after suspending the thread. */
>   CONTEXT  base_context;
> #endif
> 
>   /* The context of the thread, including  any manipulations.  */
>   CONTEXT  context;
> 
> <<<<<<<<<<<  add `char  dummybuffer[1024];' or some such here.
> 
> } win32_thread_info;
> 
> If the  theory is correct, then GetThreadContext will
> clobber the dummy buffer  instead of some other random thing.
> 
> -- 
> Pedro Alves
>