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

[Danny Backx <danny.backx@scarlet.be>]

On Wed, 2009-08-12 at 15:11 +0100, Pedro Alves wrote:
> Sorry, I'm quite behind on reading cegcc-devel@.  Do you now have a
> fully working non-broken libstdc++ dll (the dll that triggered this
> problem)?  IIUC from the binutils posts, the runtime loader was ending
> up doing things it shouldn't do to the dll image in memory.

Summary on the "broken DLL" issue : in the gcc port, I wasn't emitting
the type info for the function symbols. This made binutils (dlltool)
behave in the wrong way, which in turn resulted in relocations that
didn't happen right.

Now that this is understood, I don't see how this can have influence on
the gdbserver/ReadProcessMemory issue. But before understanding this,
your question was certainly valid.

But in order to be more certain, here's output I created just now of an
unfixed gdbserver :

(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
                        No          li
                        No          \Windows\coredll.dll
(gdb) 

Here is output with my fix :

(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?

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.

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.

	Danny
-- 
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info