Unfinished projects

Unfinished projects

[Stan Shebs]

Andrew's sudden departure from GDB maintenance seems to left a
large number of projects in mid-process; as I'm picking through
the latest sources trying to figure out how to merge with Apple's
bits, it's very confusing as to how the new way is supposed to
work when it's not documented anywhere and there's maybe only
one example of a configuration using it.

So my question is - what should we do about all these? Are
some of these intrinsically impossible to complete without
the right collection of hardware? If so, then maybe we need
to get tougher about dropping support for some targets, or
else abandon the projected change. I'd like to work on updating
the GDB internals manual too, for my own understanding if
nothing else; should I describe old ways, new ways, or both?

Stan

Re: Unfinished projects

[Daniel Jacobowitz]

On Thu, Apr 14, 2005 at 11:55:11AM -0700, Stan Shebs wrote:
> Andrew's sudden departure from GDB maintenance seems to left a
> large number of projects in mid-process; as I'm picking through
> the latest sources trying to figure out how to merge with Apple's
> bits, it's very confusing as to how the new way is supposed to
> work when it's not documented anywhere and there's maybe only
> one example of a configuration using it.
> 
> So my question is - what should we do about all these? Are
> some of these intrinsically impossible to complete without
> the right collection of hardware? If so, then maybe we need
> to get tougher about dropping support for some targets, or
> else abandon the projected change. I'd like to work on updating
> the GDB internals manual too, for my own understanding if
> nothing else; should I describe old ways, new ways, or both?

Could you give some specific examples that you're looking at?  I've got
no way to answer your questions without more details.  For each one,
there's probably someone on the list who knows how it's supposed to
work.

Converting that knowledge into better internals documentation would,
obviously, be great.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Unfinished projects

[Stan Shebs]

Daniel Jacobowitz wrote:

>On Thu, Apr 14, 2005 at 11:55:11AM -0700, Stan Shebs wrote:
>
>>Andrew's sudden departure from GDB maintenance seems to left a
>>large number of projects in mid-process; as I'm picking through
>>the latest sources trying to figure out how to merge with Apple's
>>bits, it's very confusing as to how the new way is supposed to
>>work when it's not documented anywhere and there's maybe only
>>one example of a configuration using it.
>>
>>So my question is - what should we do about all these? Are
>>some of these intrinsically impossible to complete without
>>the right collection of hardware? If so, then maybe we need
>>to get tougher about dropping support for some targets, or
>>else abandon the projected change. I'd like to work on updating
>>the GDB internals manual too, for my own understanding if
>>nothing else; should I describe old ways, new ways, or both?
>>
>
>Could you give some specific examples that you're looking at?  I've got
>no way to answer your questions without more details.  For each one,
>there's probably someone on the list who knows how it's supposed to
>work.
>
I was being purposefully vague because I wanted to think about
general strategy, and because I don't even know how many there
are. Specific things I've noticed include async for native, the
infptrace vs inf-ptrace situation, and then there's everything
with "deprecated" somewhere in the name.

So that would be a start - what are all the main incomplete
transitions in the code right now?

Stan

Re: Unfinished projects

[Mark Kettenis]

   Date: Thu, 14 Apr 2005 11:55:11 -0700
   From: Stan Shebs <shebs@apple.com>

   Andrew's sudden departure from GDB maintenance seems to left a
   large number of projects in mid-process; as I'm picking through
   the latest sources trying to figure out how to merge with Apple's
   bits, it's very confusing as to how the new way is supposed to
   work when it's not documented anywhere and there's maybe only
   one example of a configuration using it.

   So my question is - what should we do about all these? Are
   some of these intrinsically impossible to complete without
   the right collection of hardware? If so, then maybe we need
   to get tougher about dropping support for some targets, or
   else abandon the projected change. I'd like to work on updating
   the GDB internals manual too, for my own understanding if
   nothing else; should I describe old ways, new ways, or both?

If anything, only document the new way.  Out of the top of my head I
don't know any newly introduced mechanisms that really have been
abandoned.  But indeed there are many mechanisms that have not been
adapted by all targets.

The problem is that we have many targets for which there is not a
maintainer, and some targets for which the maintainer has been "lazy".
We have never really made it the responsibility of the maintainers to
update their targets to use the new ways of doing this, and I think we
should.

That said, I don't really consider documenting the mechanisms a big
priority.  I think a set of targets that use the proper mechanisms is
much more important.  I usually don't completely get how things are
supposed to work until I see some good code that uses a particular
mechanism.  But because we have many targets that still use the
outdated hacks it isn't always obvious what the proper mechanisms are.
To make matters worse, I think the most "obvious" code to look isn't
always the best code to look at to understand how things are supposed
to work; in some respects this is particularly true for Linux/i386.

Of the targets I'm familliar with, these targets are basically clean:

* sparc/sparc64, m88k, vax, i386/amd64

These are mostly clean, but still need some work:

* m68k, powerpc, mips/mips64, alpha

And these still need a serious amount of work:

* arm, hppa, ia64

On the native support side things are a bit more murky.  The *BSD
natives mostly use up-to-date mechanisms, but the Linux world is in
quite a bit of disarray.  The problem here is that Linux native
support is scattered over many people and a ridiculous number of Linux
targets is basically unmaintained.  We really need someone with an
overview to work on making the Linux stuff more uniform.

Then of course there is the embedded side of things.  Here there is a
tendency of companies contributing support for their own chip with
their own remote protocol and then abandoning it.  There seems to be
almost no interest for folks to work on the common infrastructure for
debugging embedded stuff.  This leaves us with quite a bit of cruft.

But the most serious problem is the fact that development of out
symbol readers has basically stopped.  The round-trip for having
patches reviewed in this area is in the order of weeks, and this is
not encouraging other people to work on it (to use an understatement).

Feel free to nominate targets for removal; there probably still is
quite a bit of dead wood in our tree.

Mark

Re: Unfinished projects

[Russell Shaw]

Mark Kettenis wrote:
>    Date: Thu, 14 Apr 2005 11:55:11 -0700
>    From: Stan Shebs <shebs@apple.com>
> 
>    Andrew's sudden departure from GDB maintenance seems to left a
>    large number of projects in mid-process; as I'm picking through
>    the latest sources trying to figure out how to merge with Apple's
>    bits, it's very confusing as to how the new way is supposed to
>    work when it's not documented anywhere and there's maybe only
>    one example of a configuration using it.
> 
>    So my question is - what should we do about all these? Are
>    some of these intrinsically impossible to complete without
>    the right collection of hardware? If so, then maybe we need
>    to get tougher about dropping support for some targets, or
>    else abandon the projected change. I'd like to work on updating
>    the GDB internals manual too, for my own understanding if
>    nothing else; should I describe old ways, new ways, or both?
> 
> If anything, only document the new way.  Out of the top of my head I
> don't know any newly introduced mechanisms that really have been
> abandoned.  But indeed there are many mechanisms that have not been
> adapted by all targets.
> 
> The problem is that we have many targets for which there is not a
> maintainer, and some targets for which the maintainer has been "lazy".
> We have never really made it the responsibility of the maintainers to
> update their targets to use the new ways of doing this, and I think we
> should.
> 
> That said, I don't really consider documenting the mechanisms a big
> priority.  I think a set of targets that use the proper mechanisms is
> much more important.  I usually don't completely get how things are
> supposed to work until I see some good code that uses a particular
> mechanism.  But because we have many targets that still use the
> outdated hacks it isn't always obvious what the proper mechanisms are.
> To make matters worse, I think the most "obvious" code to look isn't
> always the best code to look at to understand how things are supposed
> to work; in some respects this is particularly true for Linux/i386.
> 
> Of the targets I'm familliar with, these targets are basically clean:
> 
> * sparc/sparc64, m88k, vax, i386/amd64
> 
> These are mostly clean, but still need some work:
> 
> * m68k, powerpc, mips/mips64, alpha
> 
> And these still need a serious amount of work:
> 
> * arm, hppa, ia64
> 
> On the native support side things are a bit more murky.  The *BSD
> natives mostly use up-to-date mechanisms, but the Linux world is in
> quite a bit of disarray.  The problem here is that Linux native
> support is scattered over many people and a ridiculous number of Linux
> targets is basically unmaintained.  We really need someone with an
> overview to work on making the Linux stuff more uniform.
> 
> Then of course there is the embedded side of things.  Here there is a
> tendency of companies contributing support for their own chip with
> their own remote protocol and then abandoning it.  There seems to be
> almost no interest for folks to work on the common infrastructure for
> debugging embedded stuff.  This leaves us with quite a bit of cruft.
> 
> But the most serious problem is the fact that development of out
> symbol readers has basically stopped.  The round-trip for having
> patches reviewed in this area is in the order of weeks, and this is
> not encouraging other people to work on it (to use an understatement).
> 
> Feel free to nominate targets for removal; there probably still is
> quite a bit of dead wood in our tree.
> 
> Mark
> 

I'd create a new gdb copy that only has the maintained stuff in it, so it
can all be easily cleaned up. Then if someone needs one of the unmaintained
targets, they can use the old gdb, or port that stuff from the old gdb to
the new gdb.

Re: Unfinished projects

[Eli Zaretskii]

> Date: Fri, 15 Apr 2005 11:52:15 +1000
> From: Russell Shaw <rjshaw@netspace.net.au>
> Cc: gdb@sources.redhat.com
> 
> I'd create a new gdb copy that only has the maintained stuff in it

No, please let's not do it.  There's no reason to abruptly discontinue
support for configurations that still build and work, even if they use
some deprecated code.

Re: Unfinished projects

[Eli Zaretskii]

> Date: Thu, 14 Apr 2005 11:55:11 -0700
> From: Stan Shebs <shebs@apple.com>
> 
> Andrew's sudden departure from GDB maintenance

Did he really depart?  Is that departure final or just temporary, and
if the latter, for how much time?

> seems to left a
> large number of projects in mid-process; as I'm picking through
> the latest sources trying to figure out how to merge with Apple's
> bits, it's very confusing as to how the new way is supposed to
> work when it's not documented anywhere and there's maybe only
> one example of a configuration using it.

I agree with Daniel: please list the problems and issues you need to
resolve, and let's deal with them one by one.

> So my question is - what should we do about all these? Are
> some of these intrinsically impossible to complete without
> the right collection of hardware? If so, then maybe we need
> to get tougher about dropping support for some targets, or
> else abandon the projected change.

I think we need to answer these questions on the per issue basis.

> I'd like to work on updating the GDB internals manual too, for my
> own understanding if nothing else; should I describe old ways, new
> ways, or both?

Obviously, I'd be the first to applaud the documentation effort (if
you need any help, please tell).  In general, I agree with Mark here:
let's document the new ways, and only mention the old ones where it's
important for those who convert from widely used old ways.

Re: Unfinished projects

[Andrew Cagney]

Que?

Re: Unfinished projects

[Stan Shebs]

Andrew Cagney wrote:

> Que?

OMG, you're alive! You're allliivvve! <sob> <tears of joy>

Well, for the foreseeable future, fingers crossed, I'm going
to have cycles to work on FSF GDB as well as Apple's version,
and hopefully incorporate a bunch of Apple's improvements. Some
of this is going to be messy, because for instance Apple's
basic Darwin support depends somewhat on having async for
native working, but I think there are enough generic goodies
to make it worth the trouble.

Also, though being careful not to promise too much, I'd
like to crank on some of the unfinished conversion projects.

Stan

Re: Unfinished projects

[Alain Magloire]

> 
> Andrew Cagney wrote:
> 
> > Que?
> 
> OMG, you're alive! You're allliivvve! <sob> <tears of joy>
> 

[[laughs]] 8-)
Sorry, ROTFL

The flag was half mast, here.