generic code duplication in Ada files

[Joel Brobecker <brobecker@adacore.com>]

Daniel is a bit concerned by the code duplication that is occurring
inside the Ada files (mostly ada-lang.c I believe). Because it's been
the status quo for a while, Daniel didn't reject some patches I recently
submitted, but I certainly heard his comments. Let me try to open up
my mind a bit, and see if that might answer some of those concerns.

I don't want to force these changes onto the GDB project if they are
going to cause disatisfaction. I'm trying to find what's best given
the current situation. It's going to be a while before we start
unifying this code back together, but this is definitely something
we also want to do.

We could work on making these cleanups in our tree until we're ready
to reveal an improved version of the Ada support. But this cleanup
will touch what I call the core files, and I like to have feedback
when I make these types of changes, just to make sure that I'm going
in a direction that satisfies everyone. Sometimes, what's obvious to me
can be strange to others.

In the past, I've asked for feedback for changes that I could then
not contribute because the changes were based on some code that was
not perfect yet. I felt uncomfortable because I was getting advice
and not giving back in return. This time, I want things to be
different. I want Ada enthusiasts to be able to download the debugger
from the FSF and have an enjoyable experience using it.

We can make happen in the relatively near future. Doing it the other
way will take, I am afraid, quite a bit of time.  The cost of compromise
is the semi-duplication that we have now. I can see that it can cause
some maintenance trouble.  But I promise in return that I will help
in any way I can: fix the maintenance situations that might arise,
and improve the situation in the long run.

In the meantime, having the AdaCore sources and the FSF sources
be as close as possible allow us to:

  - Effectively test on a regular basis the FSF debugger against
    our testsuite, which contains quite a few testcases that we
    can't contribute.

  - Work on the cleanup in one debugger without having to worry
    about the other one. 

Typically, my work-flow would involve doing the cleanup in the FSF
tree, get it reviewed and checked in, and then push it to our tree.
That way, I'm sure that any change I make finds its way to the FSF
tree rapidly instead of sitting in our tree first, sometimes forever.

So, any objection if I took advantage of the current status-quo for
a little while longer?  There are no more patches coming except
the ones that are still under review, so we're close to the end
of the tunnel.

-- 
Joel