From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11785 invoked by alias); 24 May 2013 08:07:35 -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 11686 invoked by uid 89); 24 May 2013 08:07:34 -0000 X-Spam-SWARE-Status: No, score=-4.6 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL autolearn=ham version=3.3.1 Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Fri, 24 May 2013 08:07:32 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1Ufn2A-00072e-EZ from Yao_Qi@mentor.com ; Fri, 24 May 2013 01:07:30 -0700 Received: from SVR-ORW-FEM-04.mgc.mentorg.com ([147.34.97.41]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 24 May 2013 01:07:29 -0700 Received: from qiyao.dyndns.org (147.34.91.1) by svr-orw-fem-04.mgc.mentorg.com (147.34.97.41) with Microsoft SMTP Server id 14.2.247.3; Fri, 24 May 2013 01:07:30 -0700 Message-ID: <519F1FD9.8060307@codesourcery.com> Date: Fri, 24 May 2013 08:07:00 -0000 From: Yao Qi User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: Pedro Alves CC: Subject: Re: [RFC] Don't create inferior in tfile target. References: <1367631071-20079-1-git-send-email-yao@codesourcery.com> <5193AAD0.1030808@redhat.com> In-Reply-To: <5193AAD0.1030808@redhat.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2013-05/txt/msg00912.txt.bz2 On 05/15/2013 11:33 PM, Pedro Alves wrote: > I have a very vague recollection that it was I who suggested this > in internal reviews at the time, but GDB was a bit different then, > and I don't recall exactly why. It's possible you might find that > in CS's archives. I went through the CS's archives (in a range of 3 years), but didn't find anything related to it. > I was going to say this would break "detach" with tfile > (detach_command checks for null_ptid). Except "detach" with tfile > doesn't work already -- with target core, Yes, this patch changes the behaviour of "detach" on tfile, without this patch, there is no output after command 'detach'. (gdb) detach However, with this patch, GDB prints something, (gdb) detach The program is not being run. > "detach" unloads the core, and I assumed tfile behaved the same. > I think it'd be reasonable if it did. 'detach' uploads the core, but I don't think 'detach' should behave the same in tfile target. The GDB manual says about 'detach' command: "When you have finished debugging the attached process, you can use the detach command to release it from gdb control. Detaching the process continues its execution. After the detach command, that process and gdb become completely independent once more, and you are ready to attach another process or start one with run." User can use 'detach' command to release the process from gdb control. Command 'detach' applies to core file, because the pid of the process which core file is dumped is stored in core file, so GDB can 'emulate' the pid of the core file. However, the tfile and ctf doesn't save the pid in it (unnecessary to do so on the other hand), so command 'detach' doesn't apply to tfile. The output "The program is not being run." of command 'detach' on tfile is reasonable to me. > > You didn't mention it explicitly, so I'll ask. > There are probably more commands that treat null_ptid magically. > Could you audit kill, detach, continue, step, etc. > to see if they'll do something reasonable? Or rather, The commands 'step', 'continue' behave the same, while command 'kill' behaves differently. Without this patch, (gdb) kill Kill the program being debugged? (y or n) y You can't do that without a process to debug. With this patch, (gdb) kill The program is not being run. According to the GDB manual, 'kill' command is "Kill the child process in which your program is running under gdb", we don't have a child process at all on tfile, IMO, the later is more reasonable. The output of 'info threads' on tfile changes also, without this patch: (gdb) info threads Id Target Id Frame * 1 process 1 No registers. with this patch: (gdb) info threads No threads. I feel the latter is more reasonable. Without this patch command 'thread name' print nothing, but with this patch, command 'thread name' prints "No thread selected". > could you audit/grep the tree for null_ptid uses? E.g., > I see that dcache.c uses null_ptid as magic number, but > probably that doesn't matter for tfile. There don't seem > to be that many checks for null_ptid, and many are in run > control code, which obviously doesn't apply, so an audit > seems doable. I examined the null_ptid usages, looks the usages in target.c are not affected by this change. I also tried commands 'info frame' and 'maintenance print registers', the output is the same. In short, this patch changes the output of some commands, but the changes are reasonable to me. WDYT? -- Yao (齐尧)