This is the mail archive of the
mailing list for the GDB project.
Re: Patch : gdbserver get_image_name on CE
- From: Danny Backx <danny dot backx at scarlet dot be>
- To: Pedro Alves <pedro at codesourcery dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Wed, 01 Jul 2009 20:40:48 +0200
- Subject: Re: Patch : gdbserver get_image_name on CE
- References: <1244903385.20290.9.camel@pavilion> <1245577804.15871.48.camel@pavilion> <1246396039.15871.152.camel@pavilion> <email@example.com>
- Reply-to: danny dot backx at scarlet dot be
On Tue, 2009-06-30 at 22:58 +0100, Pedro Alves wrote:
> On Tuesday 30 June 2009 22:07:19, Danny Backx wrote:
> > > Is the rest of my patch acceptable or are there things I need to
> > > address ?
> > >
> Did you get to confirm what really that ERROR_PIPE_NOT_CONNECTED
> is about?
I am certain that this happens when you create an executable which
attempts to get an API from a DLL by name, if the API happens not to be
in the DLL.
You'll probably need to read that five times to understand it :-)
If the development environment is wrong in this way :
- a .def file was used to create a .dll.a file
- the .def file implements an api that's not actually in the DLL
This could be due to
- an invalid .def file
- a .def file that's valid for one distribution of WinCE but not for
another (read: differences between CE versions)
Anyway. What happens is the executable appears to start (CreateProcess
returns valid results), then the loader kicks in and fails. This is
where I have verified that you will get this result.
Furthermore : none of the debug API's work either, gdbserver really gets
not a single sensible signal from the underlying process.
> Could you post an updated, cleaned up patch, without any extra
> unnecessary bits removed, along with change log entry, using
> 'cvs diff -up'?
> And you never did explain what was broken with get_image_name
> that you had to fix, as I asked $n emails ago, right?
Err. I am almost certain that the return value of GetProcessMemory isn't
a reliable way to verify success. Its final parameter is. Or at least
that is my experience. Of course, MSDN docs don't mention this.
I tested this on ARM and on i386. Real devices, not emulators. The ARM
implementation worked as it was, and continued to work after my fix. The
i386 version didn't work before, does work after the fix.
Is this sufficient explanation?
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info