This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Patch : gdbserver get_image_name on CE


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.
> 
> > > 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.

The cause turns out to be the obvious one, if you read the above well.
The setjmp call is documented on MSDN but my experiments show that the
coredll.dll doesn't offer it on the platform I'm using.

Therefore, an application that tries to fetch it from the DLL will
simply not start up.

I've looked at the gdbserver code. The only two reasons I see for using
setjmp/longjmp are :
- to call kill_inferior () if you're beyond some point
- to end up at the "restart:" point

I see three options :
- write a setjmp replacement, put it in utils.c, and leave the rest of
  the code as is.
- remove setjmp/longjmp and just exit in that one place where longjmp
  is called
- improve the code so errors are always treated well without relying
  on longjmp

The last one is not something I'd like to start. My current code
basically implements the second one, I'm not sure what would be going
wrong if this would be implemented generally.

A final note : detecting this situation automatically at configure time
is not obvious because of the cross-compile.

Opinions ?

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]