GDB's low hanging backlog

GDB's low hanging backlog

[Andrew Cagney]

Hello,

GDB's got a number of those almost complete changes that never seem to 
go away.  While these are things that don't attract the glamor of key 
new features, they are equally important as by closing these tasks off 
we ensure that GDB is moving forward in a steady and healthy way.

I'd like to see a few of these tasks finally closed, and with a bit of 
focused effort we can do it.

Here's what's I see as relatively low hanging fruit:


-- builtin_type_* as a function

The builtin_types have finally been moved to the architecture vector. 
The task of going through GDB and switching to the per-architecture 
method remains.

The tricky area is the language code.


-- shlibs in architecture vector

I guess it needs a final shove?  Anything else holding it up?


-- tm*.h removal a.k.a. true multi-arch

See above for road blocks.  I _think_ that's it!   GDB being able to 
support both native and remote debugging for mixed architectures becomes 
a reality.


-- xm*.h removal
Thanks to Joel, AIX is [almost] fixed.  That just leaves the DOS file 
formats.


-- i18n

We need to get GDB's strings marked up.


Also lurking in the wings are:


-- CXX compile

GCC's ahead of us here and already started the process.  It should be 
possible to build GDB using the C++ compiler (which is very different to 
GDB being written in C++ :-).


-- nm*.h removal

Probably not so easy.  The contents should be either in the architecture 
or target vector.


What have I forgotten?

Who would like to help?

Andrew

Re: GDB's low hanging backlog

[Michael Chastain]

Something on my list:

-- configuration --with-ncurses=...

I can't build gdb for alpha*-dec-osf5.1a because the machine I use
has a curses library that does not work with gdb.

I can build ncurses on this machine, but I have no way to tell gdb
to use it!

I'm not a configury expert, but I would like it very much if I could
configure gdb with my choice of curses library, readline library,
and any other libraries that it uses.

Michael C

Re: GDB's low hanging backlog

[Andrew Cagney]

[-- Attachment #1: Type: text/plain, Size: 6 bytes --]

Ping.

[-- Attachment #2: Attached Message --]
[-- Type: message/rfc822, Size: 4383 bytes --]

From: Andrew Cagney <cagney@gnu.org>
To: gdb@sources.redhat.com
Subject: GDB's low hanging backlog
Date: Sun, 08 Aug 2004 18:00:39 -0400
Message-ID: <4116A287.7000108@gnu.org>

Hello,

GDB's got a number of those almost complete changes that never seem to 
go away.  While these are things that don't attract the glamor of key 
new features, they are equally important as by closing these tasks off 
we ensure that GDB is moving forward in a steady and healthy way.

I'd like to see a few of these tasks finally closed, and with a bit of 
focused effort we can do it.

Here's what's I see as relatively low hanging fruit:


-- builtin_type_* as a function

The builtin_types have finally been moved to the architecture vector. 
The task of going through GDB and switching to the per-architecture 
method remains.

The tricky area is the language code.


-- shlibs in architecture vector

I guess it needs a final shove?  Anything else holding it up?


-- tm*.h removal a.k.a. true multi-arch

See above for road blocks.  I _think_ that's it!   GDB being able to 
support both native and remote debugging for mixed architectures becomes 
a reality.


-- xm*.h removal
Thanks to Joel, AIX is [almost] fixed.  That just leaves the DOS file 
formats.


-- i18n

We need to get GDB's strings marked up.


Also lurking in the wings are:


-- CXX compile

GCC's ahead of us here and already started the process.  It should be 
possible to build GDB using the C++ compiler (which is very different to 
GDB being written in C++ :-).


-- nm*.h removal

Probably not so easy.  The contents should be either in the architecture 
or target vector.


What have I forgotten?

Who would like to help?

Andrew

Re: GDB's low hanging backlog

[Baurjan Ismagulov]

Hello, Andrew!

On Tue, Aug 24, 2004 at 03:43:57PM -0400, Andrew Cagney wrote:
> -- i18n
> -- CXX compile

I could try one of these if I finish the test case soon. Why is the
latter important?

With kind regards,
Baurjan.

Re: GDB's low hanging backlog

[Orjan Friberg]

Andrew Cagney wrote:
> -- tm*.h removal a.k.a. true multi-arch
> 
> See above for road blocks.  I _think_ that's it!   GDB being able to 
> support both native and remote debugging for mixed architectures becomes 
> a reality.

What about the various watchpoint-related defines?  (The existing frv 
target defines those, and my upcoming CRISv32 does also.)

-- 
Orjan Friberg
Axis Communications

Re: GDB's low hanging backlog

[Andrew Cagney]

> Hello, Andrew!
> 
> On Tue, Aug 24, 2004 at 03:43:57PM -0400, Andrew Cagney wrote:
> 
>>> -- i18n
>>> -- CXX compile
> 
> 
> I could try one of these if I finish the test case soon. Why is the
> latter important?

Yes, i18n is far more important than CXX compile.

CXX compile, however is medium/long term strategic.  As with GCC we need 
to start clearing obsticals blocking an eventual migration to an OO 
language (and failing that, C++ :-).

Andrew

Re: GDB's low hanging backlog

[Andrew Cagney]

> Andrew Cagney wrote:
> 
>> -- tm*.h removal a.k.a. true multi-arch
>>
>> See above for road blocks.  I _think_ that's it!   GDB being able to support both native and remote debugging for mixed architectures becomes a reality.
> 
> 
> What about the various watchpoint-related defines?  (The existing frv target defines those, and my upcoming CRISv32 does also.) 

They should be in the target or architecture vector.

Andrew