From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9882 invoked by alias); 4 Feb 2014 20:57:41 -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 9870 invoked by uid 89); 4 Feb 2014 20:57:40 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 04 Feb 2014 20:57:29 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s14KvPXY000491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 4 Feb 2014 15:57:25 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s14KvNeu022036; Tue, 4 Feb 2014 15:57:24 -0500 Message-ID: <52F15433.5070305@redhat.com> Date: Tue, 04 Feb 2014 20:57:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Yao Qi CC: gdb-patches@sourceware.org, marc.khouzam@ericsson.com Subject: Re: [PATCH 0/2] Create inferior fro trace file target References: <1391060652-10870-1-git-send-email-yao@codesourcery.com> In-Reply-To: <1391060652-10870-1-git-send-email-yao@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-02/txt/msg00028.txt.bz2 On 01/30/2014 05:44 AM, Yao Qi wrote: >> To me, trace records are like a limited core file: >> a snapshot of a specific point of the execution. So, when looking >> at a trace record, just like when looking at a core file, we want >> to show the execution hierarchy, i.e., the process and thread >> where the record was collected. > > The corefile has information about thread and process, but trace file > doesn't. Thread and process is not mentioned in the "Trace File Format" > doc https://sourceware.org/gdb/current/onlinedocs/gdb/Trace-File-Format.html I agree with Marc here, in that looking at a traceframe is like looking at a corefile. I don't think he is implying that the code is similar. Only that a corefile is a snapshot of the program at a given point in time, and so is a traceframe. It just happens that the traceframe often doesn't include the contents of all of the inferior's memory, but so can a core -- e.g. we print when printing memory/registers of trimmed core files too. > Keeping trace file similar to core file is unspecified, and their code > are total independent to each other. It is not good for Eclipse to > assume that, unless we can extend trace file format to include the > process id and the thread id in each trace frame. I think the availability of the specific process id and thread ids is a bit orthogonal to GDB modelling the existence of processes/threads or not. We can always say that "there's a process, but we don't know its PID". In fact, we do that for cores too. That's the real question -- what model makes sense. In any case, it makes sense to me to say that inferior foo has been bound to some kind of execution object, like in the old: =thread-group-started Here we have to read "thread-group" in MI as "inferior". The thread-group is a concept pre-dates "info inferiors", and can be seen as sort of a misnomer. > Reverting my patch works, which is included in patch 1/2. > In patch 2/2, I add something similar to ctf target, and a test case. > Patches are regression tested on x86_64-linux. They are also tested > on x86-linux with babeltrace installed. > > In short, Eclipse replies on an undocumented GDB behavior, that GDB > should provide inferior and thread when reading a trace file while I > don't think GDB has to. If global maintainers think GDB 7.7 shouldn't > break Eclipse, then we should pick these two patches up. > > These two patches bring an issue for multi-target support, say if GDB > opens two trace files in two targets, what is the expected output of > "info inferiors" and "info threads"? We've moved in the direction of "always a thread" a while ago, so in the current model, both tfiles would be listed in the latter command (but we can always revisit that once we get to multi-target). As for "info inferiors", seems to me the tfiles should both be listed somehow irrespective of the process/thread model. In any case, both patches look OK to me, and I agree it's best to avoid breaking Eclipse since we don't have a really good reason to change behavior compared to previous releases right now. So, OK for both. Thanks for fixing this. We've talked about setting up a build bot in the gcc compile farm. If that goes forward, it'd be great if we had some sort of Eclipse + mainline GDB auto testing setup there as well. Marc, OOC, can the Eclipse+gdb testsuite run unattended? -- Pedro Alves