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: Pedro Alves <pedro at codesourcery dot com>
- To: danny dot backx at scarlet dot be
- Cc: gdb-patches at sourceware dot org
- Date: Wed, 1 Jul 2009 19:53:32 +0100
- 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>
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 :-)
--
Pedro Alves