* GDB's low hanging backlog
@ 2004-08-09 13:58 Andrew Cagney
2004-08-09 16:28 ` Michael Chastain
2004-08-24 19:45 ` Andrew Cagney
0 siblings, 2 replies; 7+ messages in thread
From: Andrew Cagney @ 2004-08-09 13:58 UTC (permalink / raw)
To: gdb
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: GDB's low hanging backlog
2004-08-09 13:58 GDB's low hanging backlog Andrew Cagney
@ 2004-08-09 16:28 ` Michael Chastain
2004-08-24 19:45 ` Andrew Cagney
1 sibling, 0 replies; 7+ messages in thread
From: Michael Chastain @ 2004-08-09 16:28 UTC (permalink / raw)
To: gdb, cagney
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: GDB's low hanging backlog
2004-08-09 13:58 GDB's low hanging backlog Andrew Cagney
2004-08-09 16:28 ` Michael Chastain
@ 2004-08-24 19:45 ` Andrew Cagney
2004-08-24 22:38 ` Baurjan Ismagulov
2004-08-25 8:22 ` Orjan Friberg
1 sibling, 2 replies; 7+ messages in thread
From: Andrew Cagney @ 2004-08-24 19:45 UTC (permalink / raw)
To: Andrew Cagney; +Cc: gdb
[-- 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: GDB's low hanging backlog
2004-08-24 19:45 ` Andrew Cagney
@ 2004-08-24 22:38 ` Baurjan Ismagulov
2004-08-27 16:04 ` Andrew Cagney
2004-08-25 8:22 ` Orjan Friberg
1 sibling, 1 reply; 7+ messages in thread
From: Baurjan Ismagulov @ 2004-08-24 22:38 UTC (permalink / raw)
To: gdb
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: GDB's low hanging backlog
2004-08-24 22:38 ` Baurjan Ismagulov
@ 2004-08-27 16:04 ` Andrew Cagney
0 siblings, 0 replies; 7+ messages in thread
From: Andrew Cagney @ 2004-08-27 16:04 UTC (permalink / raw)
To: Baurjan Ismagulov; +Cc: gdb
> 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: GDB's low hanging backlog
2004-08-24 19:45 ` Andrew Cagney
2004-08-24 22:38 ` Baurjan Ismagulov
@ 2004-08-25 8:22 ` Orjan Friberg
2004-08-27 16:16 ` Andrew Cagney
1 sibling, 1 reply; 7+ messages in thread
From: Orjan Friberg @ 2004-08-25 8:22 UTC (permalink / raw)
To: Andrew Cagney; +Cc: gdb
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: GDB's low hanging backlog
2004-08-25 8:22 ` Orjan Friberg
@ 2004-08-27 16:16 ` Andrew Cagney
0 siblings, 0 replies; 7+ messages in thread
From: Andrew Cagney @ 2004-08-27 16:16 UTC (permalink / raw)
To: Orjan Friberg; +Cc: gdb
> 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
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2004-08-27 16:16 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-08-09 13:58 GDB's low hanging backlog Andrew Cagney
2004-08-09 16:28 ` Michael Chastain
2004-08-24 19:45 ` Andrew Cagney
2004-08-24 22:38 ` Baurjan Ismagulov
2004-08-27 16:04 ` Andrew Cagney
2004-08-25 8:22 ` Orjan Friberg
2004-08-27 16:16 ` Andrew Cagney
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).