Re: Is GDB support for IPv6 useful?

[Jan Kratochvil <jan dot kratochvil at redhat dot com>]

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 <<HERE >>/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