Re: Ping (Re: Patch : gdbserver get_image_name on CE)

[Pedro Alves <pedro@codesourcery.com>]

On Wednesday 12 August 2009 16:17:50, Danny Backx wrote:
> (gdb) info share
> >From        To          Syms Read   Shared Object Library
>                         No          \Windows\iphlpapi.dll
>                         No          \Windows\ws2.dll
>                         No          \network\x86\ace\libgcc_s_sjlj-1.dll
>                         No          \network\x86\ace\libstdc++-6.dll
> 0x41f21000  0x420d9744  Yes         libace.dll
>                         No          \Windows\coredll.dll
> (gdb) 
> 
> > Does this
> > ReadProcessMemory problem still exist with a fixed dll?  Did you ever
> > see this problem with another dll?

Well, both these dlls have considerable size, they're both written
in C++, and they were both generated from your toolchain.  Maybe that's
a coincidence, but maybe not.  I don't know how other
folks tend to catch these issues, but one thing I would do would be to
either remove things from the dll until I could reproduce it with
a *minimal* dll, or go the other way around, start with a minimal
dll that doesn't have  the problem, and add things until the
problem appears.  There's the other issue that CE isn't reporting
full paths for these dlls.  It doesn't look like a coincidence to me.

> Yes, and yes. See above. The one that shows it in this output is not the
> DLL that had that other problem (that was libstdc++-6.dll).

> 
> >   I'm very relunctant to this
> > fix without understanding it fully, and without having seen it
> > trigger with a sane dll, and not really understanding why some dlls
> > cause it and other don't, even though they're apparently built
> > the exact same way --- not because I'm hard headed, but because
> > these workarounds tend to mask other real problems.  From what
> > I've heard so far, this only triggered on that broken dll.  I wonder if
> > anyone has tried loading an application with a dll that triggers
> > this into MSFT's debugger, and see if it reads the dll name correctly.
> 
> I understand your point. But they're separate issues. I do have to admit
> I don't know what's causing it.

Don't you want to know what is?

> I'll look into your code style comments and submit a new patch, unless
> you want other information before I start going down that path.

I give up.  Let's follow this road then.

-- 
Pedro Alves