From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20501 invoked by alias); 11 Mar 2002 16:06:54 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 20439 invoked from network); 11 Mar 2002 16:06:53 -0000 Received: from unknown (HELO kerberos.suse.cz) (195.47.106.10) by sources.redhat.com with SMTP; 11 Mar 2002 16:06:53 -0000 Received: from chimera.suse.cz (chimera.suse.cz [10.20.0.2]) by kerberos.suse.cz (SuSE SMTP server) with ESMTP id 0A52A59D352; Mon, 11 Mar 2002 17:06:52 +0100 (CET) Received: from suse.cz (leviathan.suse.cz [10.20.1.56]) by chimera.suse.cz (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id g2BG6pp02294; Mon, 11 Mar 2002 17:06:51 +0100 X-Authentication-Warning: chimera.suse.cz: Host leviathan.suse.cz [10.20.1.56] claimed to be suse.cz Message-ID: <3C8CD61B.8070704@suse.cz> Date: Mon, 11 Mar 2002 08:06:00 -0000 From: Michal Ludvig Organization: SuSE CR User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: cs, cz, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] remote debugging patches References: <3C8BA71F.20807@suse.cz> <3C8BBEFC.5040504@cygnus.com> <3C8CC863.8030206@suse.cz> <20020311103650.A9182@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-03/txt/msg00160.txt.bz2 Daniel Jacobowitz wrote: > But you had #define WAIT_FOREVER_FLAG 0. During the weekend I was debugging problems in communication between gdb(i386) and gdbserver(x8664). Whenever I was stepping through gdbserver, the other side timeouted. I've found, that last argument to getpkt() is called 'forever', but in all calls was set to '0'. I didn't want these timeouts, so I changed all occurences of 0 to WAIT_FOREVER_FLAG, which could be set in compile-time. Most users and developpers (unless they will work on remote.c or alike) will leave this unchanged to 0, but sometimes it may be handy to set to 1 and recompile. > - "no" and "yes" are useless values for a flag; they don't indicate any > meaning. Along with the name of the variable they have a meaning, I think. Of course, I can change them to 'wait'/'nowait' or 'forewer'/'timeout' or whatever else. > - You made wait_forever_flag a variable that was never changed, and > replaced a constant 0 with it... no point. Who cares? In the debugger you'll see 'yes' or 'no' when you ask for the content of wait_forever_flag. Or do 'print /d wait_forever_flag' and you will se the decimal value. > I think what Andrew had in mind was more like > > enum { > do_not_wait_forever = 0, > wait_forever = 1 > }; > > and change calls to > getpkt (blah, do_not_wait_forever) I don't understand the point of this :-( Then I'd have to change all occurences of do_not_wait_forever to wait_forever in the whole file to change the behaviour? Isn't it much easier to change just one line on top of the file from 'no' to 'yes' instead? Michal Ludvig -- * SuSE CR, s.r.o * mludvig@suse.cz * +420 2 9654 5373 * http://www.suse.cz