Re: [RFC] QNX Neutrino/i386 support

Mark Kettenis
2003-03-08T23:49:43Z

From: "Kris Warkentin" <kewarken@qnx.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