* Re: Is GDB support for IPv6 useful?
2006-10-09 19:00 ` Is GDB support for IPv6 useful? Daniel Jacobowitz
@ 2006-10-09 20:34 ` Mark Kettenis
2006-10-09 21:47 ` Jan Kratochvil
1 sibling, 0 replies; 3+ messages in thread
From: Mark Kettenis @ 2006-10-09 20:34 UTC (permalink / raw)
To: drow; +Cc: gdb
> 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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Is GDB support for IPv6 useful?
2006-10-09 19:00 ` Is GDB support for IPv6 useful? Daniel Jacobowitz
2006-10-09 20:34 ` Mark Kettenis
@ 2006-10-09 21:47 ` Jan Kratochvil
1 sibling, 0 replies; 3+ messages in thread
From: Jan Kratochvil @ 2006-10-09 21:47 UTC (permalink / raw)
To: gdb
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
^ permalink raw reply [flat|nested] 3+ messages in thread