Re: patch to add QNX NTO i386 support

[Andrew Cagney <ac131313@redhat.com>]

>> The file nm-nto.h should not be needed.  Instead define it's only macro
>>   local to remote-nto.c.  (Disclaimer, you're breaking new ground with
>> this one.  Some existing targets  don't have xm-*.h files, but I think
>> you're first with the no-*.h file).
> 
> 
> Not sure what you mean by no-*.h but I see what you mean about some of the
> short files.

tipo.  s/no/nm/.

>> >     * config/i386/nto.mh: New file
> 
>>
>> Yes, you need this, you've a native support.
> 
> 
> Cool.  I got ONE thing right. ;-)

GDB's things to do today includes break the .mh files into .mh, .mn.
At present what you see doesn't make much sense :-)


>> Can you expand on how these relate to each other?
> 
> 
> Do you want details in the ChangeLog entry other than 'new file'?  I wasn't
> sure.

Not really.  A full of contributors doesn't hurt.  However, from the 
FSF's point of view, the file only comes into existance when it is 
approved - it has no prior history.

> Yeah.  All the original code and filenames used 'qnx' and I partially
> refactored to 'nto' since it seemed more appropriate to use the OS rather
> than the company.  I suppose it wouldn't hurt to do the rest of it.

I think your decision to use nto was a good one - definitly more 
logical.  Yes, now before things get committed, is the time to finish it 
off with s/qnx/nto/.

> Thanks for all the feedback.  You've certainly given me some more work to
> keep me occupied.  You're probably right about some of the code being
> redundant.  Much of this stuff was brought forward from gdb 4.17 so there
> may be many more redundancies.  (you should have seen how much we had ripped
> out already ;-)

SNAFU.

Every branched GDB I've seen has breed superfulous[sp] changes - you 
should see the original version of the interp patch before Elena and 
then I attacked it with avengence ...

Much thanks for going through that code and stripping the unnecessary 
stuff out.  It is much easier for all concerned, saving frustration on 
both ends - the reviewer having to reject junk code out of hand, and the 
contributor wondering why their mega jumbo patch (hey it works right? 
:-) isn't simply accepted.

Andrew