From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 75014 invoked by alias); 8 Jun 2018 21:21:53 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 75002 invoked by uid 89); 8 Jun 2018 21:21:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mx1.redhat.com Received: from mx3-rdu2.redhat.com (HELO mx1.redhat.com) (66.187.233.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 08 Jun 2018 21:21:49 +0000 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3E38340BC046; Fri, 8 Jun 2018 21:21:48 +0000 (UTC) Received: from localhost (unused-10-15-17-196.yyz.redhat.com [10.15.17.196]) by smtp.corp.redhat.com (Postfix) with ESMTP id F3C3B2166BB2; Fri, 8 Jun 2018 21:21:47 +0000 (UTC) From: Sergio Durigan Junior To: Pedro Alves Cc: GDB Patches , Eli Zaretskii , Jan Kratochvil , Paul Fertser , Tsutomu Seki Subject: Re: [PATCH] Implement IPv6 support for GDB/gdbserver References: <20180523185719.22832-1-sergiodj@redhat.com> <307a63d3-703d-5611-1508-c80daa86fbbf@redhat.com> <874lieulko.fsf@redhat.com> <8721b020-3b0e-bd66-85dc-5e28aef456a8@redhat.com> <87vaattbjq.fsf@redhat.com> <745457f7-9c87-5e0e-e8df-a58900302da5@redhat.com> Date: Fri, 08 Jun 2018 21:21:00 -0000 In-Reply-To: <745457f7-9c87-5e0e-e8df-a58900302da5@redhat.com> (Pedro Alves's message of "Fri, 8 Jun 2018 19:44:15 +0100") Message-ID: <87d0x1t1n8.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2018-06/txt/msg00236.txt.bz2 On Friday, June 08 2018, Pedro Alves wrote: > On 06/08/2018 06:47 PM, Sergio Durigan Junior wrote: >> On Friday, June 08 2018, Pedro Alves wrote: > >>>>> Does connecting with "localhost6:port" default to IPv6, BTW? >>>>> At least fedora includes "localhost6" in /etc/hosts. >>>> >>>> Using "localhost6:port" works, but it doesn't default to IPv6. Here's >>>> what I see on the gdbserver side: >>>> >>>> $ ./gdb/gdbserver/gdbserver --once localhost6:1234 a.out >>>> Process /path/to/a.out created; pid = 7742 >>>> Listening on port 1234 >>>> Remote debugging from host ::ffff:127.0.0.1, port 39196 >>>> >>>> This means that the connection came using IPv4; it works because IPv6 >>>> sockets also listen for IPv4 connection on Linux (one can change this >>>> behaviour by setting the "IPV6_V6ONLY" socket option). >>>> >>>> This happens because I've made a decision to default to AF_INET (instead >>>> of AF_UNSPEC) when no prefix has been given. This basically means that, >>>> at least for now, we assume that an unknown (i.e., not prefixed) >>>> address/hostname is IPv4. I've made this decision thinking about the >>>> convenience of the user: when AF_UNSPEC is used (and the user hasn't >>>> specified any prefix), getaddrinfo will return a linked list of possible >>>> addresses that we should try to connect to, which usually means an IPv6 >>>> and an IPv4 address, in that order. Usually this is fine, because (as I >>>> said) IPv6 sockets can also listen for IPv4 connections. However, if >>>> you start gdbserver with an explicit IPv4 address: >>>> >>>> $ ./gdb/gdbserver/gdbserver --once 127.0.0.1:1234 a.out >>>> >>>> and try to connect GDB to it using an "ambiguous" hostname: >>>> >>>> $ ./gdb/gdb -ex 'target remote localhost:1234' a.out >>>> >>>> you will notice that GDB will take a somewhat long time trying to >>>> connect (to the IPv6 address, because of AF_UNSPEC), and then it will >>>> error out saying that the connection timed out: >>>> >>>> tcp:localhost:1234: Connection timed out. >>> >>> How do other tools handle this? >> >> Just like GDB. > > Well, it sounds like they do the AF_UNSPEC thing, instead of > defaulting to AF_INET. Yeah. Sorry, I was comparing with the GDB I currently have here, which uses AF_UNSPEC because I was doing a few tests and changes. >>> For example, with ping, I get: >>> >>> $ ping localhost >>> PING localhost.localdomain (127.0.0.1) 56(84) bytes of data. >>> 64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=1 ttl=64 time=0.048 ms >>> ^C >>> >>> $ ping localhost6 >>> PING localhost6(localhost6.localdomain6 (::1)) 56 data bytes >>> 64 bytes from localhost6.localdomain6 (::1): icmp_seq=1 ttl=64 time=0.086 ms >>> ^C >> >> And I get: >> >> $ ping localhost >> PING localhost(localhost (::1)) 56 data bytes >> 64 bytes from localhost (::1): icmp_seq=1 ttl=64 time=0.050 ms >> ^C >> >> $ ping localhost6 >> PING localhost6(localhost (::1)) 56 data bytes >> 64 bytes from localhost (::1): icmp_seq=1 ttl=64 time=0.089 ms >> ^C >> >> Maybe your /etc/hosts is different than mine: >> >> 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 >> ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 > > Looks like it: > > $ cat /etc/hosts > 127.0.0.1 localhost.localdomain localhost > ::1 localhost6.localdomain6 localhost6 > > This is on F27 (upgraded a few times). I don't remember if I ever > changed this manually. I've never changed mine either, but this is from a fresh F27 install. >> We can either adjust it to a lower delay, get rid of >> it, or leave it as is and assume that unprefixed addresses are IPv4. I >> fail to see what else we're missing. > > The "assume unprefixed addresses are IPv4" seems like the worse > option to me, as it's a work around. Let's tackle the real issue > instead. > > We could consider for example more verbose progress indication, > or cycling the whole "getaddrinfo loop" before waiting to retry instead > of waiting after each individual connection failure. A more verbose indication would be nice, as well as a way to control how many retries GDB should perform. I'm not sure about cycling the whole loop before waiting to retry... I mean, it works, but I'm not sure it's what the user would expect from a "retry" mechanism. I would expect GDB to "retry this address X times, and then go to the next", instead of "retry all the addresses in a loop". But that can be documented, sure. On a side note, I have to ask: why not decrease the number of retries to, say, 5? This would still add a delay, but it'd be much shorter. >> >>>>>> + char *orig_name = strdup (name); >>>>> >>>>> Do we need a deep copy? And if we do, how about >>>>> using std::string to avoid having to call free further >>>>> down? >>>> >>>> This is gdbserver/gdbreplay.c, where apparently we don't have access to >>>> a lot of our regular facilities on GDB. For example, I was trying to >>>> use std::string, its methods, and other stuff here (even i18n >>>> functions), but the code won't compile, and as far as I have researched >>>> this is intentional, because gdbreplay needs to be a very small and >>>> simple program. >>> >>> What did you find that gave you that impression? There's no reason >>> that gdbreplay needs to be small or simple. Certainly doesn't need >>> to be smaller than gdbserver. >> >> First, the way it is written. It doesn't use any of our facilities >> (e.g., i18n, strdup instead of xstrdup), and it seems to be treated in a >> "special" way, because it is a separate program. I found this message: >> >> https://sourceware.org/ml/gdb/2008-06/msg00117.html >> >> > I've tried to find information in the doc about gdbreplay without luck. >> > Really quickly, does gdbreplay, as its name suggest, allow to record an >> > re-run an application session? >> >> Yes, exactly -- but with rather stringent limits. >> In a nutshell, during the replay session, you must give >> EXACTLY the same sequence of gdb commands as were given >> during the record session. gdbreplay will prompt you for >> the next command, but if you do *anything* different, >> it will throw up its hands and quit. >> >> And it seems to imply that gdbreplay is a very limited program. > > The "stringent limits" refers to what you can do from gdb > when connected to gdbreplay, not to gdbreplay's running environment. Right, I got that. As I said, I think I read too much between the lines here. > The tool is useful for support, to e.g., reproduce bugs that only > trigger against remote stubs / embedded probes that the user has > access to, other than gdbserver. You ask the user to use "set remotelogfile" > to record the remote protocol traffic against the user's remote stub, and > then the user reproduces the bug. The user sends you the resulting > remote protocol log file, and you load it against gdbreplay. Then, using > the same gdb version and same program binary the user used, you connect > to gdbreplay, and use the exact same set of gdb commands the user used. > Given those constraints, gdb should send the exact same remote protocol > packets that the user's gdb sent to the users stub. And since gdbreplay > is replaying the remote protocol traffic the original stub sent, you'll be > able to reproduce the bug locally. If you use a different set of commands, > then gdb will send different packets, and the log that gdbreplay is > replaying of course breaks down. > > So gdbreplay runs on the host computer. There's no need to care about > making it super tiny of anything like that. We should add this to a wiki or to our official docs. I think it's the more complete explanation I've read about gdbreplay so far. Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/