Re: [RFC] QNX Neutrino/i386 support

["Kris Warkentin" <kewarken@qnx.com>]

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

Okay.  I guess I'll have to wait for someone else to pipe up.

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

Okay, I can see that.  One of the things I've been working on is untying all
our register stuff (in our own tree) because it bounces back and forth
between files so I can relate to how nasty that gets.  All there is in
i386-nto-tdep.c however is the link map stuff and the register fetch/store
functions which many tdep files have.  I just happen to do a little extra
calculating to report back regset numbers and sizes, etc. that are handy for
nto-procfs and remote-nto to know.

My plan was to have all the generic stuff in nto-tdep.c and then have hooks
for register store/fetch in the <arch>-nto-tdep.c files.  This way
nto-procfs.c and remote-nto.c get to take advantage of the same files.
Forgive my bad ascii art but we have:

nto-procfs.c__                  _i386-nto-tdep.c
              \_nto-tdep.[ch]__/_sh-nto-tdep.c
remote-nto.c__/                \_mips-nto-tdep.c, arm, ppc, ...

Where the nto-tdep.h is the interface to the arch specific back ends.

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

Alright.  I had understood that you wanted me to separate the native from
the remote but perhaps I misunderstood.  If you would like to do it this
way, it's fine by me.

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

I hope that I will eventually earn your trust but I can see your point.
Tell you what, how about you add the file as you presented it to me and then
I will start submitting additions to you.  Trust is a two way street so I
will trust you to do the right thing and help me get our support in and
working.

cheers,

Kris