From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31065 invoked by alias); 9 Oct 2006 21:47:24 -0000 Received: (qmail 31057 invoked by uid 22791); 9 Oct 2006 21:47:23 -0000 X-Spam-Check-By: sourceware.org Received: from 195.22.55.53.adsl.nextra.cz (HELO host0.dyn.jankratochvil.net) (195.22.55.53) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 09 Oct 2006 21:47:21 +0000 Received: from host0.dyn.jankratochvil.net (localhost [127.0.0.1]) by host0.dyn.jankratochvil.net (8.13.8/8.13.8) with ESMTP id k99LlICH027710 for ; Mon, 9 Oct 2006 23:47:18 +0200 Received: (from jkratoch@localhost) by host0.dyn.jankratochvil.net (8.13.8/8.13.8/Submit) id k99LlH9j027709 for gdb@sourceware.org; Mon, 9 Oct 2006 23:47:17 +0200 Date: Mon, 09 Oct 2006 21:47:00 -0000 From: Jan Kratochvil To: gdb@sourceware.org Subject: Re: Is GDB support for IPv6 useful? Message-ID: <20061009214717.GA24401@host0.dyn.jankratochvil.net> References: <20060927163337.GA27149@host0.dyn.jankratochvil.net> <20060927182038.GA5635@nevyn.them.org> <20060927185547.GA13544@host0.dyn.jankratochvil.net> <20060927190611.GA7326@nevyn.them.org> <20060930152757.GA27372@host0.dyn.jankratochvil.net> <20061008190239.GA29584@host0.dyn.jankratochvil.net> <20061009141634.GA392@host0.dyn.jankratochvil.net> <20061009190143.GA22487@nevyn.them.org> <20061009190037.GA22579@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061009190143.GA22487@nevyn.them.org> <20061009190037.GA22579@nevyn.them.org> User-Agent: Mutt/1.4.2.2i X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-10/txt/msg00049.txt.bz2 Hi, On Mon, 09 Oct 2006 21:00:37 +0200, Daniel Jacobowitz wrote: ... > But what I'm really interested in is whether native IPv6 support would be > useful for GDB. If it is, we should go ahead and merge it. If no one or > almost no one is ever going to want it, then we shouldn't, I am pretty sure there is currently no usefulness for IPv6 GDB as no one can drop the IPv4 interoperability nowadays. This classical chicken&egg problem needs to be solved one day, sure you have the right to avoid this pioneer step yourself. Anyway I do not consider IPv6 support for gdbserver(1) as much important, I just did not expect it will be so complicated to get it imported. On Mon, 09 Oct 2006 21:01:43 +0200, Daniel Jacobowitz wrote: > On Mon, Oct 09, 2006 at 04:16:34PM +0200, Jan Kratochvil wrote: ... > > The new syntax looks like that of socat(1): > > socat EXEC:'gdbserver fdin=3,fdout=4 emacs foo.txt',fdin=3,fdout=4 TCP-LISTEN:2345 > > We're a GNU program. We should use the standard GNU style for command > line options wherever possible. but in such case the current dualmode COMM parameter should be changed to: gdbserver --serial /dev/ttyS0 PROG gdbserver --network host:port PROG gdbserver --network udp:host:port PROG or even gdbserver --serial /dev/ttyS0 PROG gdbserver --tcp host:port PROG gdbserver --udp host:port PROG I really try to follow the current project style, in fact "fdin=3,fdout=4" was only a generalization of "fd34" which was more considered as a static keyword as it IMO does not make much sense to use other fds than 3 and 4 for socat(1). And autodetection of keyword "fd34" matches the former strchr (..., ':') autodetection of serial port vs. host:port connection type. [ I do believe there are more important GDB issues than strchr (..., ':'). ] ... > I'd prefer to avoid the "tcp6:" syntax if we can, and have things work > transparently. ... > In particular, "target remote hostname:port" ought to work fine for IPv6. It currently works fine, it will detect if IPv6 and/or IPv4 addresses exist for `hostname' and try all the available ones. "tcp6:"/"udp6:" will limit the detection only for the IPv6 types and vice versa for "tcp4:"/"udp4". Test by "ipv4.localhost." and "ipv6.localhost." by: cat <>/var/named/localhost.zone; service named restart ipv4 IN A 127.0.0.1 ipv6 IN AAAA ::1 HERE Unaware of any RFC recommendation but it is a common practive to give user the option to force the desired network connection type. Some commands like nc(1) have options "-4" vs. "-6" for it, in other cases the commands exist in two variants, such as ping(8) vs. ping6(8). I found out my patch has in some way a compatibility break - pure "host:port" originally defaulted to TCP while currently it will try in order TCP, UDP, RAW. Regards, Jan