Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@codesourcery.com>
To: danny.backx@scarlet.be
Cc: gdb-patches@sourceware.org
Subject: Re: Patch : gdbserver get_image_name on CE
Date: Sun, 14 Jun 2009 14:34:00 -0000	[thread overview]
Message-ID: <200906141534.24103.pedro@codesourcery.com> (raw)
In-Reply-To: <1244972893.20290.71.camel@pavilion>

On Sunday 14 June 2009 10:48:13, Danny Backx wrote:
> On Sun, 2009-06-14 at 10:47 +0200, Danny Backx wrote:
> > On Sat, 2009-06-13 at 19:05 +0100, Pedro Alves wrote:
> > > > 2. Handle a case where the inferior refuses to start. See the
> > > >    code after WaitForDebugEvent in win32-low.c .
> > > 
> > > This is quite mystifying.  Do you have more details on this?
> > 
> > Not yet, but as I said in the other message, the a simple setjmp demo
> > application is an example. Other cases I've seen were with invalid
> > requirements to a DLL (use of an API that was not in the DLL). On a
> > PocketPC, this causes a dialog to pop up. On Windows Embedded CE the
> > application appears just not to start up.

Huh, it has nothing to do with GUIs and popups.  The fact that this
doesn't result in CreateProcess returning ERROR_BAD_EXE_FORMAT is what
is quite mystifying.  Did you find any reference to this
ERROR_PIPE_NOT_CONNECTED case anywhere else?  So this supposedly
happens when the debug api is reporting the initial list of loaded
dlls?  Here's a test you could make to make it a bit clearer what
is happening:  make a simple test app that doesn't reference any
non-existing system function.  Make a couple of simple dlls, in which
one of them calls setjmp or whatever other function non-exiting
function.  Make the app link to these dlls.  Load it under gdbserver.
Check if WaitForDebugEvent reports any events, like loading coredll.dll
before reporting that ERROR_PIPE_NOT_CONNECTED.  I would guess from
your description that WaitForDebugEvent would fail when the faulty
dll is loaded.  BTW, trying the load the faulty dll dynamicaly
with LoadLibrary would hopefully fail gracefully, otherwise, you
may have found a kernel bug...

> > 
> > > > 3. Setjmp won't work on this platform, I've "#if 0"-ed it out.
> > > >    Clearly not the right solution. Comment please.
> > > 
> > > What does "won't work on this platform" mean?  If longjmp
> > > doesn't work, then you probably have a bug in your
> > > headers or import libs?  I'd suspect _JBLEN in the
> > > mingw headers.


> > I've been thinking about that too, I'll try to debug this but that's
> > hard with no debugger.

You *do* have a debugger.  You can debug gdbserver with gdbserver itself.

-- 
Pedro Alves


  parent reply	other threads:[~2009-06-14 14:34 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-13 14:29 Danny Backx
2009-06-13 18:05 ` Pedro Alves
2009-06-13 18:08   ` Pedro Alves
2009-06-14  8:35     ` Danny Backx
2009-06-14 13:56       ` Pedro Alves
2009-06-14  8:47   ` Danny Backx
2009-06-14  9:48     ` Danny Backx
2009-06-14 14:23       ` Pedro Alves
2009-06-21  9:50         ` Danny Backx
2009-06-30 21:07           ` Danny Backx
2009-06-30 21:56             ` Pedro Alves
2009-07-01 18:41               ` Danny Backx
2009-07-01 18:52                 ` Pedro Alves
2009-07-01 19:12                   ` Danny Backx
2009-07-01 20:12                 ` Pedro Alves
2009-07-04 18:14                   ` Pedro Alves
2009-07-08  9:55                     ` Danny Backx
2009-07-08 11:34                       ` Danny Backx
2009-07-27 20:40                         ` Danny Backx
2009-07-01 19:31               ` Danny Backx
2009-06-14 14:34       ` Pedro Alves [this message]
2009-06-14 14:05     ` Pedro Alves
  -- strict thread matches above, loose matches on Subject: below --
2009-06-07  9:18 Danny Backx
2009-06-07 17:03 ` Pedro Alves
2009-06-07 18:02   ` Danny Backx
2009-06-07 18:15     ` Pedro Alves
2009-06-07 19:13       ` Danny Backx
2009-06-07 19:28         ` Pedro Alves
2009-06-08 18:13           ` Danny Backx
2009-06-12 22:18       ` Danny Backx
2009-06-13  6:28         ` Johnny Willemsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200906141534.24103.pedro@codesourcery.com \
    --to=pedro@codesourcery.com \
    --cc=danny.backx@scarlet.be \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox