This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re : [gdbserver][WinCE][ARM] gdbserver crash: issue with GetThreadContext???
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
>