From: Stan Shebs <shebs@cygnus.com>
To: brendan@dgs.monash.edu.au
Cc: gdb@cygnus.com
Subject: Re: GDB: one version for all targets
Date: Thu, 01 Apr 1999 00:00:00 -0000 [thread overview]
Message-ID: <199902232219.OAA07851@andros.cygnus.com> (raw)
In-Reply-To: <36CA2891.A1C43ED2@dgs.monash.edu.au>
Date: Wed, 17 Feb 1999 13:25:21 +1100
From: Brendan Simon <brendan@dgs.monash.edu.au>
>From some of the discussions on this list, I have interpretted that GDB may
be moving to one version that can dynmically detect the CPU target and ABI
type. A manual setting for these is provided as a fallback if autodetection
fails.
Does this mean there would only be one GDB that would cater for all targets.
eg. i386, powerpc, m68k, etc ?
Yes, that ought to be possible some day. It would it to be like a config
option, a la BFD's --with-targets=all.
This sounds like a fantastic idea and I look forward to such a versatile
debugger.
Does anyone know when this is likely to be available ?
It's going to be awhile. This is more of a direction, not a scheduled
commitment, and availability is going to be depend on how many people
actually work on this. Can't depend on Cygnus to do it all, since among
other things we don't even have all the targets inhouse to test.
I assume the correct simulator would be called based on the above settings.
The existing builtin simulators all present the same API, and thus are
not set up to link in more than one. However, it would be sensible to
build sims into gdbserver and have a single debugger able to talk with
any of the servers.
To reduce diskspace, would it be possible to have the supported targets and
ABI types as some kind of shared library or plug in module ?
That would certainly be a good way to implement. In practice, most
users don't care, because it primarily matters to embedded developers
using multiple architectures at once. It's going to be a long time
before a single GDB can be both a native x86 Linux and PA HP-UX debugger! :-)
The real value in this sort of change is for things like
multiprocessor cross-debugging, which is an exotic activity nowadays,
but I expect it will become more common in the future.
Stan
prev parent reply other threads:[~1999-04-01 0:00 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <199812041858.KAA25185.cygnus.gdb@jtc.redbacknetworks.com>
1998-12-10 19:27 ` breakpoint extension for remote protocol Andrew Cagney
1998-12-10 21:46 ` Stu Grossman
1998-12-11 11:59 ` J.T. Conklin
1998-12-11 14:30 ` J.T. Conklin
1998-12-11 11:24 ` J.T. Conklin
[not found] ` <13936.45476.191551.329690.cygnus.gdb@babylon-5.cygnus.com>
1999-04-01 0:00 ` Andrew Cagney
1999-04-01 0:00 ` J.T. Conklin
1999-04-01 0:00 ` Stan Shebs
1999-04-01 0:00 ` Jim Blandy
1999-04-01 0:00 ` Stan Shebs
1999-04-01 0:00 ` J.T. Conklin
1999-04-01 0:00 ` GDB: one version for all targets Brendan Simon
1999-04-01 0:00 ` Stan Shebs [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=199902232219.OAA07851@andros.cygnus.com \
--to=shebs@cygnus.com \
--cc=brendan@dgs.monash.edu.au \
--cc=gdb@cygnus.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox