Re: patch to add QNX NTO i386 support

[Daniel Jacobowitz <drow@mvista.com>]

On Thu, Feb 13, 2003 at 04:56:58PM -0500, Kris Warkentin wrote:
> > > #define HANDLE_SVR4_EXEC_EMULATORS 1
> > > #include "solib.h" /* shared lib support */
> >
> > Including solib.h is fine.  However I wonder why you need
> > HANDLE_SVR4_EXEC_EMULATORS.  AFAIK this deals with Solaris BCP
> > (running SunOS 4 a.out files on Solaris 2 a.k.a. SunOS 5).  What is
> > its relevance on QNX?  Could this be the reason that you need to set
> > SOLIB_BKPT_NAME?
> 
> I've discovered why HANDLE_SVR4_EXEC_EMULATORS is needed but I'm not sure of
> the correct way to fix it.  The relevant code is from solib-svr4.c below.  A
> typical remote qnx debugging session would be something like this:
> 
> kewarken@CATDOG ~/test
> $ ntox86-gdb
> GNU gdb 5.2.1qnx-326 QNX Neutrino 6.2.1
> Copyright 2002 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "--host=i686-pc-cygwin --target=ntox86".
> (gdb) target qnx ren:10000
> Remote debugging using ren:10000
> (gdb) sym blah
> Reading symbols from blah...done.

Silly question - why not say "file blah" here?  That'll set exec_bfd,
and you'll be just fine.

If I'm right, and you want to support the above sequence, you could
probably locally make sym set the exec file, if none was set.

> (gdb) upload blah /tmp/blah
> (gdb) r /tmp/blah
> Starting program:  /tmp/blah
> (gdb) b main
> Breakpoint 1 at 0x8048402: file blah.c, line 10.
> (gdb) c
> Continuing.
> 
> Breakpoint 1, main () at blah.c:10
> 10              func();
> 
> The problem that we're running into is that exec_bfd is NULL in the code
> below so we fall back on the 'hard way' which is not really necessary (if
> exec_bfd is set).  On the native qnx gdb, this isn't a problem because
> exec_bfd is set when main() calls attach_command() which calls
> exec_file_attach().  What I'd like to know is at what point should I stuff
> exec_bfd?  In the case of remote debugging, the file with the symbols is
> '/home/kewarken/test/blah' and the file being run (on the remote) is
> /tmp/blah.  We need to set exec_bfd to point to the same file as the one
> we've read symbols from but the question is, when and where?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer