From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31240 invoked by alias); 17 Oct 2007 22:00:44 -0000 Received: (qmail 31226 invoked by uid 22791); 17 Oct 2007 22:00:42 -0000 X-Spam-Check-By: sourceware.org Received: from ug-out-1314.google.com (HELO ug-out-1314.google.com) (66.249.92.171) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 17 Oct 2007 22:00:39 +0000 Received: by ug-out-1314.google.com with SMTP id o2so399030uge for ; Wed, 17 Oct 2007 15:00:36 -0700 (PDT) Received: by 10.67.20.19 with SMTP id x19mr1080841ugi.1192658436469; Wed, 17 Oct 2007 15:00:36 -0700 (PDT) Received: from ?88.210.68.128? ( [88.210.68.128]) by mx.google.com with ESMTPS id e1sm4646361ugf.2007.10.17.15.00.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 17 Oct 2007 15:00:35 -0700 (PDT) Message-ID: <471685D3.7060402@portugalmail.pt> Date: Thu, 18 Oct 2007 04:06:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-BR; rv:1.8.1.6) Gecko/20070728 Thunderbird/2.0.0.6 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Joel Brobecker CC: Ulrich Weigand , Eli Zaretskii , gdb-patches@sourceware.org Subject: Re: Support of gdb for Windows 64 native systems References: <200710161823.l9GIN1Vu023163@d12av02.megacenter.de.ibm.com> <47165541.90206@portugalmail.pt> <20071017194708.GC2068@adacore.com> In-Reply-To: <20071017194708.GC2068@adacore.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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 X-SW-Source: 2007-10/txt/msg00442.txt.bz2 Joel Brobecker write: >>>> I will double-check this when I get a chance, but I think the current >>>> patches should provide relatively complete support. From what I could >>>> tell, the "attach" feature might not be working (apparently, we need >>>> to define the "ATTACH_NO_WAIT" macro), and we have to implement IO >>>> redirection / process creation through a shell. I think these are >>>> the only two major features that we should be missing. >> Attaching already works nicelly. > > Since you've played with the resulting debugger, how would you > categorize the current support? I think it's good enough for > a NEWS entry already. > Admitelly, I didn't didn't do anything with it besides playing with it, no serious debugging. I didn't notice anything lacking, so for me it's good enough. I quickly tried running the testsuite on it, but for some reason it refused to work. So I tried unload.exp manually, and confirmed that I could step into a dll. > Do you know of anything else that's missing ... No, my itch is gone for now :) (but it may come back). > ... except using a shell > to do the process creation (which will also allow us to do IO > redirection)? > I don't think talking about a (unix) shell in a native Windows gdb makes sense, and I don't know if running through 'cmd /c' has the wanted effect. There's these 'HANDLE hStdInput, hStdOutput, hStdError' in STARTUPINFO which may be passed into the CreateProcess call to redirect io. Yet another way is to use GetStdHandle/SetStdHandle much like one uses dup2 on unix. In both these alternatives we'll have to do args processing (<,>, etc) ourselves. But, is this considered a basic feature? I seldom use it myself. I don't think it is a show stopper. Cheers, Pedro Alves