Re: Patch : gdbserver get_image_name on CE

[Danny Backx <danny.backx@scarlet.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