Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@false.org>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [patch] IPv6 support for gdbserver
Date: Wed, 27 Sep 2006 19:06:00 -0000	[thread overview]
Message-ID: <20060927190611.GA7326@nevyn.them.org> (raw)
In-Reply-To: <20060927185547.GA13544@host0.dyn.jankratochvil.net>

On Wed, Sep 27, 2006 at 08:55:47PM +0200, Jan Kratochvil wrote:
> On Wed, 27 Sep 2006 20:20:38 +0200, Daniel Jacobowitz wrote:
> ...
> > focused on the environment you're working in (Red Hat Linux).
> ...
> > I suspect that this would break GDB builds on a number of targets
> 
> I was thinking about this a bit, forgot to write a not while posting it...
> Yes, the current patch is not portable - as it does not need to be.
> I was thinking whether to post the patch at all as IMO it does not make much
> sense (nowadays) for gdb to support IPv6, just Red Hat requires it.
> 
> Still I do not want to invest a lot of time for the autoconf/portability stuff
> if it gets dropped down upstream (like by you) afterwards anyway (sometimes
> right, no problem with it).  It should have been marked more as "RFC" patch.
> 
> It is fine for me to update the patch upon request if it gets merged this way.
> Still it is not acceptable for me to rewrite the patch from scratch just for
> the upstream without reusability for Red Hat (as I was feeling for the case of
> SIGSTOP vs. ptrace(2) due to a different kernel variant in use).
> At least I do not think I am expected to do this in RH.
> 
> 
> I hope I cleared it up; I try to be upstream-cooperative.

Thanks!  The RFC-ness wasnt clear; I'm much happier now :-)

I don't have an opinion on whether GDB should support IPv6 connections;
it's not an important feature to me, but I think it would be reasonable
to add.  Let's see if anyone else has a thought on it.

> > Maybe we should add stdin/stdout support to gdbserver and make an
> > external utility handle any more fancy networking scenarios.  I'm
> > thinking of "socat" here.  What do you think of that idea?  We've done
> > stdin/stdout for other stubs in the past and it's quite handy. Or if
> > you want to leave inferior stdout alone you can use two specified file
> > descriptors.
> 
> I do not know, I used only gdb stub or gdbserver on full GNU/Linux.
> Still I feel it is more complicated to compile both stripped-down gdbserver AND
> IPv6-enabled socat and connect them together on the target UNIX system than
> just to compile there the IPv6-enabled (autoconf-configured) gdbserver.
> 
> Still it looks simple enough to provide the fd interface for gdbserver, if it
> is going to be imported upstream.

The advantage of providing just an fd interface is that you can leave
writing complicated networking code to people who are more dedicated
to it, and people who don't need ipv6 on their embedded device with 
gdbserver won't have to include the code.  Gdbserver isn't exactly
small - in fact as stubs go it's pretty heavyweight!  But I do still
try to keep the bloat limited.

I'd offer to do this, but don't count on my having time for it any
time soon.  I still need to go through and review a lot of other
submissions to gdb-patches since the last time I had a break from
work, including yours.

-- 
Daniel Jacobowitz
CodeSourcery


  reply	other threads:[~2006-09-27 19:06 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-27 16:33 Jan Kratochvil
2006-09-27 18:20 ` Daniel Jacobowitz
2006-09-27 18:56   ` Jan Kratochvil
2006-09-27 19:06     ` Daniel Jacobowitz [this message]
2006-09-30 15:28       ` Jan Kratochvil
2006-10-08 19:03         ` Jan Kratochvil
2006-10-09  4:33           ` Eli Zaretskii
2006-10-09 14:17             ` Jan Kratochvil
2006-10-09 19:01               ` Daniel Jacobowitz
2006-10-09 19:36               ` Eli Zaretskii

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=20060927190611.GA7326@nevyn.them.org \
    --to=drow@false.org \
    --cc=gdb-patches@sourceware.org \
    --cc=jan.kratochvil@redhat.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