Re: [RFC] QNX Neutrino/i386 support

[Mark Kettenis <kettenis at chello dot nl>]

   From: "Kris Warkentin" <kewarken at qnx dot com>
   Date: Sat, 8 Mar 2003 10:06:49 -0500

   That's great Mark but what about the native procfs stuff?

Sorry but the native procfs stuff is beyond my maintainership, and I
don't feel confident enough to approve that stuff based on my global
maintainership.

   The most recent patch that I had submitted was a native only
   version.  The only stuff in the i386-nto-tdep.c that was even
   vaguely related to the remote protocol was stuffing the regset type
   in the register area.  This is also used by nto-procfs.c so I
   refactored the regset numbers to be defines that can be used by
   both.

The i386-nto-tdep.c (and the nto-tdep.c for that matter) should only
contain ISA/ABI related code.  You'll probably need some register
mapping functions in there (for interpreting core files), but I fail
to see how the code that's in your proposed i386-nto-tdep.c file is
related to the rest of the stuff.  There just seem to be too many
interdependencies between all the different files.

   The file you have reduced to here is completely useless for any
   form of debugging on Neutrino.  We don't currently support the
   standard gdb debug protocol although it's on our to-do list.  Our
   i386 registers are in a different order that gdb so we need to do
   the mapping.  I have already applied patches to solib.c to do a
   special lookup of target solibs.  Without that support, libs won't
   be found properly.

I understand that, and I'm not asking you to implement the standard
GDB remote protocol before we can add this to GDB.

   BTW, the OSABI stuff is already committed (they gave me write-after
   approval for cvs) - the only stuff left is the addition of new
   files.  I would like to get the config dir stuff, the tdep files,
   the nto-share headers and nto-procfs.c committed.

But I hope you can understand that you can't just drop in those new
files.  Dropping in large chunks of code makes it difficult to get
approval.  If you can split things up in smaller chunks that don't
need approval of several people, you're much more likely to get
approval.  As a benefit you'll probably get code that's structure more
like the way we'd like GDB to evolve.  That's the main reason why I
(and Andrew before me) have asked you to seperate the target-dependent
bits from the native and remote support and ask approval for those
bits seperately.

   What we have currently is something that works perfectly for us.  I
   really don't want to start with something completely broken and
   make additions until it works.  I want to add the working stuff and
   then cut away any fat that we can prove that we don't need.  I
   don't mind doing major refactoring but I want to have working code
   in CVS at all times.  That is something that the GDB project
   strives for and I would like to do for our target as well.

   I've attached a tarball with the files in it.  I think that it's
   pretty much the same as what you have with the changes for the
   remote defines.  I appreciate the time you're putting into this and
   I really want our port to be as clean as it can be.  I know that
   there's lots of work to be done but I'd really rather start from a
   working version and clean from there.  This is one of my highest
   priority projects so I have lots of cycles available to do the work
   but I want to be able to point our customers to the head branch and
   have it work for them.

We have seen in the past that such cleanups hardly ever happen.  Would
it be acceptable for you to check the new files in on a branch and
merge it in bit by bit from there?

Mark