[RFC] QNX Neutrino/i386 support
Kris Warkentin
kewarken@qnx.com
Sun Mar 9 14:54:00 GMT 2003
> 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
More information about the Gdb-patches
mailing list