generic code duplication in Ada files

generic code duplication in Ada files

[Joel Brobecker]

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

Re: generic code duplication in Ada files

[Daniel Jacobowitz]

On Tue, Jan 29, 2008 at 02:33:42PM -0800, Joel Brobecker wrote:
> 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 came across angrier than I really felt, by the way.  I apologize.

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

This is exactly what I was hoping for.  The duplication has been
status quo for many years; I don't mind it continuing that way, and
once we're in sync you'll have the option of doing restructuring on
the FSF tree, getting it right, and then importing it into your local
sources - much more palatable.

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

Hey, I hadn't even read this paragraph yet and I've already suggested
the same thing above!  Great!

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

And that's what I was going to ask.  Also great.  As long as the file
is not growing unboundedly, we're making progress :-)

Some of the things in Ada-specific code will be a mess to get into
common code, but IMO clearly worthwhile.  For instance, a version of
symbol lookup which can return more than one symbol.

-- 
Daniel Jacobowitz
CodeSourcery

Re: generic code duplication in Ada files

[Paul Hilfinger]

> Some of the things in Ada-specific code will be a mess to get into
> common code, but IMO clearly worthwhile.  For instance, a version of
> symbol lookup which can return more than one symbol.

I am glad to hear you say that.  Our original reason for this
duplication, as you probably guessed, was to avoid disturbing core GDB 
"merely" for the sake of accommodating a less-familiar language.  Our
assumption was that any major maintenance headaches that resulted
would be our problem.  But apart from this political motivation, a
major refactoring at this point would clearly be beneficial.

Paul Hilfinger

RE: generic code duplication in Ada files

[Pierre Muller]

> -----Original Message-----
> From: gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] On Behalf Of Paul Hilfinger
> Sent: Wednesday, January 30, 2008 12:50 AM
> To: Daniel Jacobowitz
> Cc: Joel Brobecker; gdb-patches@sourceware.org
> Subject: Re: generic code duplication in Ada files
> 
> 
> > Some of the things in Ada-specific code will be a mess to get into
> > common code, but IMO clearly worthwhile.  For instance, a version of
> > symbol lookup which can return more than one symbol.

  But pascal language has the same feature:
  variables with the same name can coexist in different units,
either in the interface part (accessible to other units or the main program
if they reference the unit in the USES clause) or private
in the implementation part.
  I am not sure the degugging information provided is
always precise enough to be able to sort out which variable
the compiler has chosen when a variable multiply defined is used.

  Anyhow, getting the list of all public versions of
a given name would be great for pascal language too.

Pierre Muller
Pascal language support maintainer

Re: generic code duplication in Ada files

[Joel Brobecker]

> This is exactly what I was hoping for.  The duplication has been
> status quo for many years; I don't mind it continuing that way, and
> once we're in sync you'll have the option of doing restructuring on
> the FSF tree, getting it right, and then importing it into your local
> sources - much more palatable.

I'm really glad to see that we have the same ideas on how to move
forward. That's great!

I'll go ahead and check in the patches that you already approved.

-- 
Joel