Is GDB support for IPv6 useful?

Is GDB support for IPv6 useful?

[Daniel Jacobowitz]

Jan Kratochvil posted patches on the gdb-patches mailing list which add
support for both "target remote" connecting to IPv6 targets, and gdbserver
listening on IPv6 targets.

You can already simulate this behavior for GDB, by using "target remote |"
in combination with a helper like socat.  If support were added to gdbserver
for using arbitrary file descriptors - not hard, as you can see from Jan's
latest patch - it could do the same.

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, and I can write
up some text for the manual about how to use an external program to
implement it.

I have never used IPv6, for debugging or anything else, so I don't feel able
to make a useful decision about this.  I'd like to hear from some people who
do use it.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Is GDB support for IPv6 useful?

[Mark Kettenis]

> Date: Mon, 9 Oct 2006 15:00:37 -0400
> From: Daniel Jacobowitz <drow@false.org>
> 
> Jan Kratochvil posted patches on the gdb-patches mailing list which add
> support for both "target remote" connecting to IPv6 targets, and gdbserver
> listening on IPv6 targets.
> 
> You can already simulate this behavior for GDB, by using "target remote |"
> in combination with a helper like socat.  If support were added to gdbserver
> for using arbitrary file descriptors - not hard, as you can see from Jan's
> latest patch - it could do the same.

I think native IPv6 support would be preferable if there actually
people using it.

> 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, and I can write
> up some text for the manual about how to use an external program to
> implement it.
> 
> I have never used IPv6, for debugging or anything else, so I don't feel able
> to make a useful decision about this.  I'd like to hear from some people who
> do use it.

Me neither.

Mark

Re: Is GDB support for IPv6 useful?

[Jan Kratochvil]

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