From: Thomas Schwinge <tschwinge@gnu.org>
To: gdb@sourceware.org
Subject: Re: gdbserver for GNU/Hurd
Date: Thu, 30 Jul 2009 22:54:00 -0000 [thread overview]
Message-ID: <20090730225444.GA25983@fencepost.gnu.org> (raw)
In-Reply-To: <20061223212245.GA1091@nevyn.them.org>
[-- Attachment #1: Type: text/plain, Size: 2001 bytes --]
Hello!
On Sat, Dec 23, 2006 at 04:22:45PM -0500, Daniel Jacobowitz wrote:
> On Sat, Dec 23, 2006 at 04:31:55PM +0100, Mark Kettenis wrote:
> > Thomas Schwinge wrote:
> > > [Idea about porting gdbserver to GNU/Hurd.]
> > >
> > > In case you don't know: this would allow for debugging programs on
> > > GNU/Hurd systems using a cross debugger running on another system (e.g. a
> > > non GNU/Hurd one). This is of advantage if you're cross compiling and
> > > then don't have to copy the source files to the target system for using
> > > gdb locally on there.
I'd like to have a go at that one. My motivation is the following one,
as I already quickly told above: I build a complete GNU/Hurd toolchain
and a bootable base system using cross compiling. Then I can strip the
resulting binaries and transfer them over a rather low-bandwidth line to
a native GNU/Hurd machine, to test them. Of course, we do have a usable
native port of GDB, but for that one to be really usable, I'd also have
to transfer all the unstripped binary files, plus source code files to
the remote machine, which I want to avoid.
> > But it'd be difficult to have access to all the advanced features a
> > native GNU/Hurd GDB offers.
>
> It shouldn't be hard to add anything necessary to the remote protocol
> and if anyone was interested in working on it I'd be glad to offer
> advice.
OK, I understand that. But even for those parts that are covered by the
current remote protocol, I understand this correctly that we can't
directly use the implementation in native GDB's gnu-nat.c, but instead
have to (re-)write that stuff for gdbserver usage? That is, there is no
way to relay from the GDB remote protocol (or any other to-be-written
remote protocol) into a native GDB again? (Which I'd imagine to be
useful also for non-GNU/Hurd systems, isn't it?, as it would make remote
GDB support available for all architectures a native GDB port exists
for.)
Regards,
Thomas
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
prev parent reply other threads:[~2009-07-30 22:54 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-23 11:10 Thomas Schwinge
2006-12-23 14:56 ` Alfred M. Szmidt
2006-12-23 15:14 ` Thomas Schwinge
2006-12-23 15:32 ` Mark Kettenis
2006-12-23 21:22 ` Daniel Jacobowitz
2006-12-27 18:22 ` Barry deFreese
2006-12-28 1:53 ` Daniel Jacobowitz
2009-07-30 22:54 ` Thomas Schwinge [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=20090730225444.GA25983@fencepost.gnu.org \
--to=tschwinge@gnu.org \
--cc=gdb@sourceware.org \
/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