This is the mail archive of the
gdb-patches@sourceware.org
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 21:12:11 +0200
- Subject: Re: Patch : gdbserver get_image_name on CE
- References: <1244903385.20290.9.camel@pavilion> <200906302258.00604.pedro@codesourcery.com> <1246473648.15871.201.camel@pavilion> <200907011953.32584.pedro@codesourcery.com>
- Reply-to: danny dot backx at scarlet dot be
On Wed, 2009-07-01 at 19:53 +0100, Pedro Alves wrote:
> On Wednesday 01 July 2009 19:40:48, Danny Backx wrote:
> > 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 :-)
>
> Nope, I got it the first time. :-)
>
> >
> > 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.
> >
>
> What I was interested in knowing, was if loading a similarly faulty
> dll (not the main executable) triggers the same issue. Both in the
> case where the app is "linked" to it (gcc -o foo foo.c -lbaddll) ---
> I expect so, and in the case where LoadLibrary is used to pull in a
> bad dll. If the latter case triggers the same "lost connection to
> inferior" error, then you have yourself a kernel bug.
>
> You'll probably need to read that five times to understand it :-)
Hmm :-)
I verified the LoadLibrary case. I believe the LoadLibrary call returned
the right error message (ERROR_DLL_INIT_FAILED, 1114L).
I don't have the evidence of that test any more though.
Danny
--
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info